• Dates: Wed, August 21 - Sun, August 25, 2013
• Venue: University Aarhus, Denmark
• Host: Erik Ernst

Participants

Top row: Jonathan Edwards, Ronald Garcia, James Noble, Erik Ernst, Crista Lopes, John Hughes, Leo Meyerovich, Robby Findler

Bottom row: Eelco Visser, Tijs van der Storm, Stefan Hanenberg, Laurie Tratt, Yannis Smaragdakis, Adam Chlipala

More photos of this and previous WGLD meetings can be found in our flickr group.

Proceedings

The following talks were given during the meeting:

• Introductions
• Jonathan Edwards: Dynamic → Static
• Tijs van der Storm: Abstract Syntax Sucks!^?
• Robby Findler: 2D syntax
• Lars Bak (special guest from Google): Dart
• Stefan Hanenberg: Experiment with Dart typing
• Erik Ernst: Relevance in Programming Languages^?
• John Hughes: QuickCheck your language design^?
• Crista Lopes: Exercises in Style
• Yannis Smaragdakis: Forsaking Inheritance: Supercharged Delegation in DelphJ^?
• James Noble: Object Capabilities^?
• Leo Meyerovich: The Social Design of Graphistry
• Adam Chlipala: Feature-Level Modularity in Ur/Web^?
• Ron Garcia: Gradual Effects
• Stefan Hanenberg: A survey of experimental research in the PL literature
• Laurie Tratt: Parsing Composed Grammars with Language Boxes
• Eelco Visser: Linguistic abstractions for web programming^? (WebDSL)
• Crista: Size & superlinear effects
• Tijs van der Storm: Enso^?
• James Noble: An introduction to grounded research

Meetings

Venue: Department of Computer Science, Aarhus University, Denmark (map).

General contact: Erik Ernst, email <eernst(AT)cs.au.dk>.

Practical issues contact: Katrine Aakjær Nielsen, email <katnie(AT)cs.au.dk>, phone +45 6137 8823.

Practical issues booklet

A document containing a large amount of practical information for the meeting is available at http://cs.au.dk/~eernst/wgld13/Practicalities_WGLD_Aarhus.pdf. (July 17: New version uploaded, with small corrections).

Accommodation

Hotel: Scandic Plaza Aarhus, Banegårdspladsen 14, 8100 Aarhus C (map); phone +45 8732 0100; email meeting.aarhus(AT)scandichotels.com. Please use booking code AAR210813 and make the reservation via phone +45 8732 0101 or email plaza.aarhus@scandichotels.com (until one month before the meeting). Note that online booking is not possible with the booking code. The hotel is right across the street from the rail road station, and there is a bus stop for both airport buses mentioned below at the station.

NB: The 'one month before the meeting' deadline expired Monday July 22nd. Negotiations about an extension of this booking has enabled us to hold a few extra rooms until August 9th, using the same booking code / email address / telephone number.

Workshop fee

The workshop fee covers food coffee, lunch, dinner, and an outing.

Cost: The price is 2020 DKK (approx. $350). Please use our webshop to make the payment, no later than Sunday August 11th.

Sponsor: We are happy to announce that we have received financial support from the Alexandra Institute, which will help keeping the price similar to the price for the previous meeting, in spite of the fact that we have a 25% VAT.. By the way, the director of the Alexandra Institute is Ole Lehrmann Madsen who is a programming language design veteran (the BETA programming language).

Getting there

Travel: For historical reasons (think: evil Copenhageners) there is no airport which is really close to Aarhus. There is Aarhus Airport / AAR which is about 50km from the city (bus info on their website). However, Billund Airport / BLL is not much further away and has better connections. Finally, going via Copenhagen Airport, CPH involves a 4 hour trip by train, but the train is rather convenient: it goes directly from the airport to the center of Aarhus (train info). An extended version of this paragraph is available in the practical issues booklet as well.

Tentative Schedule

Location of the meeting

The meeting room is Ada-333; detailed information about how to find it is given in the practical issues booklet, page 6-7. Dinners and lunches also take place in the meeting room, except for the dinner Friday.

The excursion Friday goes to ARoS^? (surprisingly, finding the location using Google Maps and copy-pasting the URL does not work any more, but you can find it by pasting 'ARoS, Aros Allé 2, Aarhus, Denmark' into maps.google.com).

After the excursion, there is dinner at Restaurant Italia (paste 'Restaurant Italia, Aaboulevarden 9, Aarhus C, Denmark' into maps.google.com).

Lars Bak and Googlers on Dart

Lars Bak is managing Google's Aarhus office, and he and Mads Sig Ager have accepted an invitation to visit our meeting for a session about Google's work on language design in the context of the Dart programming language (perhaps one more Googler will come, depending on some scheduling considerations). The plan is to have a presentation by Lars Bak followed by a highly interactive phase where the real-world constraints and academic ideas can blend and/or clash, hopefully inspiring both parties. Here is the abstract:

Introduction to panel discussion about the Dart programming language

Dart is a simple yet practical programming language designed to improve productivity for web programmers. While spending years implementing V8 and integrating it into Chrome, we experienced how programmers were struggling with large JavaScript^? applications. Lack of declarations, classes, static types, and libraries you could rely on clearly created problems. Dart is an attempt to solve these issues without introducing fragmentation to the web. This panel discussion will focus on how simplicity, translation to JS, and performance goals impacted the design of Dart.

Mads Ager, Florian Loitsch, and Lars Bak, software engineers at Google.

Associated plans

In case you are making plans for events associated with this trip (e.g., if you are bringing your kids and want to visit Legoland in Billund) and you want to coordinate with other participants, you could use this space to set up the coordination.

James Noble will be accompanied by Katherine & Amy (12). We'll travel to Billund somehow on Sunday afternoon, go to Legoland on Monday 26th, fly out Monday 26 around 7pm... fly out moday

Abstracts

Yannis Smaragdakis: Forsaking Inheritance: Supercharged Delegation in DelphJ^?

We propose DelphJ^?: a Java-based OO language that eschews inheritance completely, in favor of a combination of class morphing and (deep) delegation. Compared to past delegation approaches, the novel aspect of our design is the ability to emulate the best aspects of inheritance while retaining maximum flexibility: using morphing, a class can select any of the methods of its delegatee and export them (if desired) or transform them (e.g., to add extra arguments or modify type signatures), yet without needing to name these methods explicitly and handle them one-by-one. Compared to past work on morphing, our approach adopts and adapts advanced delegation mechanisms, in order to add late binding capabilities and, thus, provide a full substitute of inheritance.

Attendance List for June 2011 Meeting

Please plan to attend for the whole meeting, which will mean arriving on 31st May and leaving on 4th June. The FCRC federated research conference, which includes PLDI, follows immediately afterwards, starting on 4th June.

Please confirm by checking below the days that you will be attending. There is an edit button at the bottom of the table; you may have to scroll to see it.

-- AndrewBlack - 24 Mar 2011

• Dates: 30 June - 4 July, 2014
• Venue: MIT, Boston
• Host: Jonathan Edwards

Officers

• Chair: Tijs van der Storm
• Vice-Chair: Heather Miller
• Secretary: Jonathan Edwards

Members

Former Members

Ivan Chermayeff wrote "Design is directed toward human beings. To design is to solve human problems by identifying them and executing the best solution." Programming languages are not just for instructing computers — they are a medium for expressing software designs and communicating such designs to other human beings. Thus, an understanding of the human element is a vital part of good language design. As a result, programming language design is not just mathematics, science, or engineering — although it involves all of these. Other fields, like Architecture, recognize Design (with a capital D) as a distinct practice with its own methodologies. Steve Jobs wrote:

In most people's vocabularies, design means veneer. It's interior decorating. It's the fabric of the curtains or the sofa. But to me, nothing could be further from the meaning of design. Design is the fundamental soul of a human-made creation.

For these reasons, this working group seeks to develop a balance between the benefits of openness and diversity and the need to maintain a high-quality membership and high-value conversations.

• Proposal for IFIP TC2 committee^?

Hotel

We have obtained a group rate at the Larkspur Landing Sunnyvale for the four nights May 31st to June 4th. The group rate is $129.00 per night for a studio suite, which includes the "Healthy Start Breakfast" (cold buffet), WiFi, parking, complimentary use of the business center and fitness center, guest laundry facilities, and fresh baked cookies served each night in the lobby.

This hotel is 5 miles from Google; some of us will probably rent cars and drive there; if there are not enough spaces in cars, then we can share taxis to get to the meeting place. For a virtual tour of the hotel, please check out their website at http://www.LarkspurLanding.com/Sunnyvale.

This is a good rate; the normal rate is about $180 per night. Part of the purpose of a Working group is to spend as much time as possible with the other members of the group: group meals and shared excursions are part of the experience. So, please try to stay at this hotel if possible. If it's too expensive, consider sharing a room with another member (you can send out requests on the mailing list.)

To make a booking:

Use this link or go to the Larkspur reservations page and enter group code GCCR75

• To get the group rate of $129 you need to make your reservation by May 24.
• This rate is not valid outside the four day period 31st May – 4th June. When I checked, the hotel does have availability outside these dates, but not at the group rate. (Saturday night is cheaper; Sunday and Monday are significantly more expensive).

Car Rental

I discovered that the http://www.alaskaair.com/shopping/car web site let me rent a car for a week (i.e., including the time for which I will be at PLDI) for less than it would cost for the 4 days of the Working Group meeting.

-- AndrewBlack - 10 May 2011

Themes and Memes

Tijs van der Storm gave a talk on "language design smells" in which he proposed an initial taxonomy. Talk of such smells repeatedly arose in later discussions, particularly William Cook's "everything is an x" smell.

We are looking forward to continuing the conversation at Austin2012.

Participants

-- JonathanEdwards - 05 Mar 2012

Program Manager for the C# Language

mads.torgersen@microsoft.com

-- MadsTorgersen - 19 May 2011

• Dates: Sunday, June 1 - Friday, June 6, 2014
• Venue: Skamania Lodge, near Portland, Oregon
• Host: Andrew Black

Skamania Lodge

I have made arrangements for five nights (Sunday to Thursday inclusive) at Skamania Lodge, http://www.skamania.com, a beautiful resort about 45 minutes drive from Portland International Airport (PDX).

I have negotiated a room rate of $110 per room per night (subject to sales tax, which is currently 7.7%, and occupancy tax, which is currently 2%). There is also a resort fee of $17 per room, which includes unlimited free local calls; 24 hour access to Technology Room; wireless high-speed internet in guestrooms, Gorge Room, Cascade Dining Room and River Rock Lounge; access to three scenic hiking trails, family putting green, health club, pool and outdoor hot tub; tennis and basketball court time; bike rentals parking, coffee in the main lobby; and a copy of the USA Today Newspaper. Total per room per night will thus be about $138. If you find this rate too high, there is always the option of sharing a room with another attendee, which will halve the rate.

To lock in this rate, you need to book your room by 28th March. Either telephone 800-221-7117 (+1 509 427 7700 from outside the USA), or go to http://www.skamania.com, and use group code 1XQ1P4 in the "Reserve a room" box at the top of the web page. (Click on Promo Code; enter the group code, and then click BOOK NOW. Alternatively, use this link to insert the dates and group code for you). After 28th March date, rooms may still be available, but may be at a higher rate. Also, the group may be subject to a penalty. So, please book early!

Skamania has an excellent restaurant, and less formal dining in the bar. I have negotiated a meal plan for us to eat together in as a group, starting with breakfast on Monday, and finishing with lunch on Friday. The meeting fee will be $500, which includes registration, audio-visual services, use of the meeting facilities, meals, and an off-site excursion.

You should plan to arrive at Skamania on Sunday evening, 1st June. Dinner on Sunday is not included in the meeting fee, but there are good options for food at the resort. The meeting will commence at 9am on Monday 2nd June, and finish with lunch on Friday, 6th June.

Transportation

The nearest airport is Portland International Airport (PDX) in the eastern suburbs of Portland, Oregon, about 50 miles west of Skamania. PDX is well-served by internal flights from all over the USA, and by international flights from Tokyo, Vancouver, Canada, and Tornonto Canada. Portland also has a Railway station with long-distance trains to Seattle, Oakland, and Chicago. The MAX light rail system connects the Railway station to the airport.

It's impractical to get to Skamania by public transport. I'm hoping that enough members have chosen to drive to Skamania, or rent a vehicle, that we are not going to hire a private bus. However, this means that you will need to coordinate ride shares amongst yourselves. Please update the spreadsheet to indicate your flight into PDX, your scheduled arrival time, and the names of the people that you plan to ride with. In case the self-organization fails, Robert Dockins (a postdoc here at PSU) has offered to rent a vehicle and drive the extra people to Skamania — taking as many trips as necessary.

If you wish to rent a car from PDX, the cheapest option appears to be Alamo, which operates from an off-airport lot (they have a shuttle pickup). Rates start at $30 per day for a midsize car ($218 per week).

Driving from PDX

The simplest route is to head South on I-205 from the airport for 1.5 miles, and then East on I-84, signposted "The Dalles". This will take you into the Columbia River Gorge on the South (Oregon) side of the River. After 36 miles, get off I-84 in Cascade Locks, cross over the Bridge of the Gods into Washington. On the Washington side of the Columbia River, turn right on WA Route 14; Skamania Lodge will be on your left in 1.5 miles. The trip should take about 45 minutes.

If you have time to spare, it is well worth while getting off of I-84 East in Troutdale (Exit 17) and taking the Columbia Gorge Scenic Highway instead of the interstate. The Scenic Highway will rejoin I-84 in Warrendale, at exit 24. The Columbia Gorge Scenic Highway will give you magnificent views and the chance to see several waterfalls and take some short walks.

Registration

Excursion

Schedule

For this meeting we are going to try a slightly different schedule than usual. Rather than meeting all day and socializing at night, we will have afternoons off and have meetings before and after dinner. You can use the afternoons for walks, discussions, work, or whatever you want. Thus, the schedule will look as follows on Monday, Tuesday, and Thursday:

• 07:00 to 09:00: breakfast
• 9:00 to 12:30: meeting (3.5 hrs)
• 12:30 to 13:30: lunch
• 13:30 to 17:00: break
• 17:00 to 19:00: meeting (2 hrs)
• 19:00 to 20:30: dinner
• 20:30 to 22:00: meeting (1.5 hrs)

On Wednesday we have an excursion, so the program will look as follows:

• 07:00 to 09:00: breakfast
• 9:00 to 12:00: meeting (3 hrs)
• 12:00 to 13:00: lunch
• 13:00 to 22:00: excursion, including dinner

On Friday we only meet in the morning:

• 09:00 to 12:00: meeting (3 hrs)
• 12:00 to 13:00: lunch
• 13:00 end of the meeting

Proceedings

MeetingProceedings2014

• Dates: April 20-24 (Mon-Fri), 2015.
• Venue: Athens, Greece
• Host: Yannis Smaragdakis

Venue

The meeting will take place at the University of Athens Club (Kostis Palamas building).

The venue is in downtown Athens, within a short walking distance of the Syntagma square (the modern center of town).

The building offers an array of options for internet access (guest access to the University network, eduroam) and a dining area for lunch. An all-day coffee and pastries buffet will be available throughout. Since laptop use during the meeting is discouraged, there will be a designated time period every day for laptop-detox (e.g., catching up and responding to urgent emails).

Accommodation

There is an abundance of hotels in the area, at all price ranges. You should prefer the areas south of the meeting venue, where most of the hotels are anyway. See the attached map for the recommended area of your hotel search. Location-wise, you will be well-served by any of the ~100 hotels in the shown map area. Even the furthest away hotels on this map are within a half hour walk, or, equivalently, a 2-stop metro ride.

Sample picks:

• Central Hotel (21 Apollonos St.): mid-range, good location for tourist areas, 1km to meeting venue.
• Amalia Hotel (10 Amalias Ave.): mid-range+, very central, next to Syntagma Square, quite close to meeting venue (<1km).
• Divani Caravel (2 Vas. Alexandrou Ave.): mid-high range, a reliably high-quality Athens hotel, 2km to meeting venue.
• Titania Hotel (52 Panepistimiou Ave. not in the map area): well-known 4-star hotel, very close to meeting venue (0.5km).
• Grande Bretagne (Syntagma square): the top luxury hotel in downtown Athens, for those wanting to splurge. <1km to meeting venue.

Registration

Registration is required, however fees will be collected at the meeting. Please register by emailing Dimitris Galipos: dgalipos@di.uoa.gr. Dimitris is in charge of all the meeting logistics.

The registration fee for the meeting is 180euros, which includes the cost for the all-day coffee buffet and lunch buffet for 5 days, as well as the cost of an excursion to the Acropolis. Dinners are not included--although we expect a planned group outing for dinner every evening, pricing and payment arrangements will be made on the spot.

Registered

• Gilad Bracha
• Edwin Brady
• James Cheney
• Adam Chlipala
• Jonathan Edwards
• Matthew Flatt
• Georgios Fourtounis
• Stefan Hanenberg
• Roberto Ierusalimschy
• Daan Leijen
• Jan-Willem Maessen
• Sean McDirmid
• Mark Miller
• James Noble
• Klaus Ostermann
• Nikolaos Papaspyrou
• Roly Perera
• Panagiotis Rondogiannis
• Kostis Sagonas
• Francisco Sant'anna
• Yannis Smaragdakis
• Ross Tate
• Sam Tobin Hochstadt
• Andrew Tolmach
• Tijs van der Storm
• Cristina Videira Lopes

Monday

Sean McDermid: Going Against the Flow for Type-less Programming

Object-oriented languages are plagued by poor support for type inference given difficulty in combining subtype and parametric polymorphism. This talk will introduce a Type-less type system that provides useful type feedback about OO code with less type annotations. Type-less rethinks type checking as a modular field-aware value flow analysis to allow inference on assignment with simplified variance and binding. Type-less also does type inference backwards to specializes term types based on their usage rather than generalizing types to validate their usage. Type annotations are then unnecessary in client code that does not define new abstractions, and greatly reduced otherwise. The result is a fluid programming experience whose feel approaches that of a dynamic language, which I will demo, of course!

Adam Chlipala: The Ur/Web People Organizer: A Library for Rapid Development of Web Apps from Components

I'll introduce a new library for the Ur/Web programming language that I talked about at past meetings of this group. Ur/Web has some novel features that support unusual and effective styles of encapsulation; I'll review those a bit. The purpose of the talk, which will focus heavily on code demos, is the new library, the Ur/Web People Organizer, which is based on a component architecture that allows very rapid assembly of applications for running meetings, etc. A growing set of components encapsulate such ideas as scheduling meetings between two groups of people, taking RSVPs for different subevents, etc. Each component has a rich static type, expressing its polymorphic dependencies on the schemas of selected SQL database tables.

Markus Völter: Experiences from building mbeddr

Over the last four years a team at fortiss and itemis have built mbeddr, an extensible set of integrated languages for embedded software development. mbeddr relies on the JetBrains^? MPS language workbench. MPS' projectional editor enables wide-ranging language modularity and flexible notations that include text, prose, tables, mathematics and diagrams. As far as we know, mbeddr is the largest and most sophisticated system built on top of a projectional language workbench. In this talk I will very briefly show mbeddr and recap the 'mbeddr experience'. In particular, I will point out the problems we had to fight with during mbeddr's construction, including those created by MPS as well as those that resulted from our own ignorance. I will close the talk by indentifying some of the areas in which MPS could be (or is currently being) improved: some of them are certainly interesting topics for academic research.

Roberto Ierusalimschy: Integers in Lua

Numerical support in programming languages is not a very glamorous subject. Nevertheless, it is a fundamental aspect of any language, and things are far from settled. Each new programming language comes with an almost unique set of number representations and sizes, coercion rules, overflow handling, etc.

Lua, unlike most other programming languages, offered only one numerical representation, (double-precision) floating-point numbers. This approach simplifies the language and also its implementation, and for many years served the needs of the language.

However, in recent years, two trends changed that situation. One is the spread of 64-bit machines, and with it the spread of 64-bit APIs, algorithms, etc. The other is the increased embedding of Lua in small devices and its use in the "Internet of Things". As a result, after much deliberation, Lua 5.3 (released Jan 2015) has incorporated (64-bit) integers. In this talk, I will discuss the process that led to this change.

Matthew Flatt: Binding as Sets of Scopes

Hygienic macro expansion is usually described as a kind of translation into lexical-scope machinery. In particular, variables must be "renamed" to match the mechanisms of lexical scope as the variables interact with macros. In a new macro expander for Racket, we discard the renaming approach and start with a generalized idea of "macro scope", where lexical scope is just a special case of macro scope when applied to a language without macros. The resulting macro system has slightly different properties than the old one, but purely pattern-based macros work as before, and the vast majority of macros in existing Racket code also continue to work. At the same time, the macro system is easier to explain and specify than one based on renaming. The corresponding implementation is simpler, and it avoids bugs that have proven too difficult to repair in the current macro expander.

Yannis Smaragdakis: Streams a la Carte: Extensible Pipelines with Object Algebras

Streaming libraries have become ubiquitous in object-oriented languages, with recent offerings in Java, C#, and Scala. All such libraries, however, suffer in terms of extensibility: there is no way to change the semantics of a streaming pipeline (e.g., to fuse filter operators, to perform computations lazily, to log operations) without changes to the library code. Furthermore, in some languages it is not even possible to add new operators (e.g., a zip operator, in addition to the standard map, filter, etc.) without changing the library.

We address such extensibility shortcomings with a new design for streaming libraries, based on treating the library as a domain-specific language interpreter. The architecture underlying this design borrows heavily from Oliveira and Cook’s object algebra solution to the expression problem, extended with a design that exposes the push/pull character of the iteration, and an encoding of higher-kinded polymorphism. We apply our design to Java and show that the addition of full extensibility is accompanied by high performance, matching or exceeding that of the original, highly-optimized Java streams library.

Jonathan Aldrich: On the Evaluation of Language Designs

How does one evaluate a language design? Clearly there are multiple modalities, including case studies, human subjects experiments, benchmarking, code corpus studies, observational studies, etc. What are the strengths and drawbacks of each? Are there examples of each in the literature that we find exemplary? I will lead a structured discussion aimed at coming to a preliminary consensus on some principles at the meeting, and identifying a subgroup interested in turning the results into a paper.

Because I am interested in starting an ongoing discussion, I would be interested in giving my talk relatively early in the week. For example, I will be prepared to give it the first day, if scheduling permits.

Tuesday

Andrew Tolmach: A Theory of Name Resolution

Joint work with Pierre Neron, Eelco Visser and Guido Wachsmuth

We describe a language-independent theory for name binding and resolution, suitable for programming languages with complex scoping rules including both lexical scoping and modules. We formulate name resolution as a two stage problem. First a language-independent scope graph is constructed using language-specific rules from an abstract syntax tree. Then references in the scope graph are resolved to corresponding declarations using a language-independent resolution process. We introduce a resolution calculus as a concise, declarative, and language-independent specification of name resolution. We develop a resolution algorithm that is sound and complete with respect to the calculus. Based on the resolution calculus we develop language-independent definitions of alpha-equivalence and rename refactoring.

Klaus Ostermann: Language Design by Duality: Making defunctionalization and refunctionalization symmetric

Reynold's defunctionalization and Danvy's refunctionalization establish a correspondence between programming with first-class functions and programming with pattern matching, but the correspondence is not symmetric: Not all uses of pattern matching can be automatically refunctionalized to uses of higher-order functions. This asymmetry makes it hard to compare the two styles of programming or convert automatically between them. We generalize from first-class functions to arbitrary codata. This leads us to a pair of languages, one with codata support based on Abel's copattern matching and one with data support based on pattern matching. They support full defunctionalization and refunctionalization.

Panagiotis Rondogiannis: Extensional Higher-Order Logic Programing

We present a purely extensional higher-order logic programming language. In this language predicates denote sets, and two predicates are equal iff they are equal as sets. Moreover, every program has a unique minimum Herbrand model which is the greatest lower bound of all Herbrand models of the program and the least fixed-point of an immediate consequence operator. In other words, we provide a purely extensional theoretical framework for higher-order logic programming which generalizes the familiar theory of classical (first-order) logic programming. We discuss an extension of the language which supports negation-as-failure, and present its semantics.

Francisco Sant'anna: Structured Synchronous Reactive Programming with Céu

Structured synchronous reactive programming (SSRP) augments classical structured programming (SP) with continuous interaction with the environment. We advocate SSRP as viable in multiple domains of reactive applications and propose a new abstraction mechanism for the synchronous language Céu: Organisms extend objects with an execution body that composes multiple lines of execution to react to the environment independently. Compositions bring structured reasoning to concurrency and can better describe state machines typical of reactive applications. Organisms are subject to lexical scope and automatic memory management similar to stack-based allocation for local variables in SP. We show that this model does not require garbage collection or a "free" primitive in the language, eliminating memory leaks for organisms by design.

Sam-Tobin Hochstadt: Pycket, a tracing JIT compiler for a functional language.

James Cheney: Teaching (about) PL Design (Discussion)

My department's previous courses on functional programming and operational semantics saw dwindling participation recently, leaving an unsightly gap between the FP and OOP basics covered in the first two years and the advanced courses taught in the fourth year. I am currently facing the challenge (and opportunity) of developing a new PL course aimed at 3rd year students, to fill this gap.

Following internal discussion, my current plan is to make language design considerations ("good", "bad", tradeoffs) a unifying theme of the course, and placing greater weight on practical experience (interpreters, DSL implementation) and less on foundations (operational semantics, specification, etc.) than our previous courses.

My totally selfish goal in this talk/discussion is to present the context motivating my current plan and provoke the audience into helping me refine and improve it; less selfishly I hope this will also lead to some transferable insights or ideas about how to make PL ideas (including the notion of, and evaluation/appreciation of PL designs, not just isolated features or "paradigms") a central selling point of a flagship PL course. If not, then at least it will be an amusing exercise for the other WGLD participants to poke holes in my current plan.

Wednesday

Edwin Brady: Uniqueness Types in Idris

I will present a newly implemented feature in the Idris programming language, Uniqueness Types, and show how they can be used in practice to implement programs with compile time guarantees on resource usage. They are inspired by a similar feature in the Clean programming language, and by Ownership Types in Rust.

A value with a uniqueness type can be used at most once in a program. This means that once used, the memory they occupy can be safely reallocated. Furthermore, it becomes possible to represent and reason about state machines directly in types. I will discuss some of the trade-offs in the design and present a practical example, namely type-safe concurrent programming.

Sophia Drossopoulou: Pony

The language Pony was developed with the aim to support easy concurrent programming, fast implementations, and data-race freedom.

In terms of case studies and benchmarks, we argue that indeed, Pony programs are fast. In terms of our and our collaborators’ programming experience, we argue that Pony is easy to learn and program in. We then outline some salient features of the Pony type system, and the garbage collection system.

Kostis Sagonas: Type Inference based on Success Typings for Erlang: A Success?

Erlang is a concurrent functional programming language designed by Ericsson to meet the needs of developing large-scale telecommunication systems. It has been designed as a dynamically typed but type safe language. For more than ten years now, Erlang is coming with static analysis tools that perform aggressive type inference based on success typings and a language for optional type declarations and function specifications. In this talk we will try to discuss whether this approach to adding types to a language designed to be dynamically typed was a good or a bad one and the lessons that have been learned in the process.

Excursion to Acropolis

After lunch we leave for an afternoon at the Acropolis

Thursday

Gilad Bracha: Implementing Access Control In Newspeak

(joint work with Ryan Macnak)

There is a natural affinity between object-based encapsulation and capability-based security. The Newspeak programming language capitalizes on this affinity. However, until recently Newspeak did not enforce access control. This is changing, and provides a clean basis for building a secure, object-capability based system.

I’ll discuss the Newspeak access control semantics and our ongoing experience in implementing and using them.

Roly Perera: Demand-indexed computation

I'll talk about an idea that came out of the work on program slicing that I did for my PhD^?.

An important role of GUIs is to provide control over the demand active on the output of a computation, via widgets like scrollpanes, collapsible lists, and tooltips. This usually means computing all the output upfront and then hiding some of it, or computing it as needed using ad hoc, application-specific logic.

A somewhat independent observation is that pattern-matching imposes a demand on the thing being pattern-matched: for example a function defined by a set of equations needs to know something (but typically not everything) about the argument in order to decide which of its defining equations is applicable.

"Tries" (a.k.a. prefix trees), extended with a notion of variable binding, can be used to formalise both of these notions of demand. I'll outline an operational semantics for a simple functional language where the demand on the output is specified explicitly in the form of a trie of a suitable type. Running the same program with more demand produces correspondingly more output. I plan to extend this with a notion of "differential" trie, representing a change in demand, plus a differential operational semantics which, given an increase in demand, does just enough extra work to produce the required extra output. Although I haven't worked this bit out yet, I'll try to explain the idea with several examples.

Ross Tate: Collaborating with Ceylon and Kotlin

I have been collaborating with the Ceylon team at Red Hat and the Kotlin team at JetBrains^? for approximately 4 years now. In these collaborations, I have not designed any languages; rather I have helped these teams make their designs have the properties that they want. In this process, I have come to understand their underlying design philosophies, many of which are motivated by their development experiences as well as what they perceive to be necessary for industry adoption. I will present my personal understanding of their perspectives, while focusing on aspects that may generalize to other industry language designs. Whether those aspects actually generalize will hopefully prompt lively discussion.

Tijs van der Storm: Demo

Crista Lopes: Big Code: What we can learn and What we can do

I will give an account of my 9-year work on mining large repositories of code towards the goal of producing the ultimate "do what I mean" programming environment. I will cover the lessons learned, both positive and not-so-positive. These lessons raise some interesting questions for programming language design.

Business Meeting

For members

Friday

Eelco Visser: Dynamic Semantics Specification in DynSem

In this talk I demonstrate the design of the DynSem language for the specification of dynamic semantics. From DynSem specifications we generate interpreter implementations in Java, which are integrated in the IDE for the object language generated by the Spoofax Language Workbench.

James Noble: Swapsies on the Internet - First Steps towards Reasoning about Risk and Trust in an Open World

Contemporary open systems use components developed by many different parties, linked together dynamically in unforeseen constellations. Code needs to live up to strict security specifications: it has to ensure the correct functioning of its objects when they collaborate with external objects of unknown provenance, and it has to protect its objects’ integrity even when external objects are malicious.

In this talk we propose specification concepts to model risk and trust in such open systems. We use these concepts to specify the escrow exchange example, and discuss the meaning of such a specification. We'll argue informally that the code satisfies its specification

Stefan Hanenberg: Discussion on Empirical Methods

"How do different empirical methods interact? And why do I (still) vote for ignoring qualitative research?"

• Dates: January 25-29, 2016
• Venue: UCLA, Los Angeles, CA
• Host: Alex Warth

Food

Lunches: grab some food in food court in Ackerman auditorium and eat outside.

Group dinners @ 7pm

• Monday: Bollywood Bites

• Tuesday: Wolfgang Puck Express (same building as the meeting room)

• Wednesday: CDG Pizza Party

• Thursday: Shamshiri Grill

All restaurants are within walking distance from the meeting room.

Wednesday: expedition to Getty center

(We will have lunch there, and dinner at CDG @ 7pm.)

Participants

Organization

• Eelco Visser (Chair)
• Jonathan Edwards (Secretary)
• Alessandro Warth (Local Organizer)

Members

• Jonathan Aldrich
• Andrew Black
• Gilad Bracha
• Kim Bruce
• Adam Chlipala
• Erik Ernst
• Robby Findler
• Matthew Flatt
• Crista Lopes
• Jan-Willem Maessen
• Sean McDirmid
• Tijs van der Storm
• Sam Tobin-Hochstadt

Visitors

• Nada Amin
• Michael Greenberg
• Heather Miller
• Todd Millstein
• Martin Odersky
• Jens Palsberg
• Manuel Serrano
• Ross Tate
• Evan Czaplicki

Monday

Introduction

• Chair's opening
• Brief round of introductions: just your name and affiliation are fine
• Local organizer's instructions

Talks

• Adam Chlipala
• Jonathan Edwards
• Andrew Black

• Robby Findler
• Jan-Willem Maessen
• Sean McDirmid

Tuesday

• Martin Odersky
• Michael Greenberg
• Todd Millstein

• Evan Czaplicki
• Jens Palsberg
• Ross Tate

Wednesday

• Alessandro Warth
• Eelco Visser
• Jonathan Aldrich

Thursday

• Tijs van der Storm
• Nada Amin
• Kim Bruce

• Crista Lopes
• Heather Miller
• Manuel Serrano

• Business meeting

Friday

• Erik Ernst

Abstracts

Kim Bruce: Teaching with Grace: First evaluations.

The pedagogical programming language Grace was designed for novices to programming. This fall was the second time we have used Grace for an intro course at Pomona College (Andrew Black has also used it with some slightly different courses at PSU).

In this talk I’ll give a quick outline of some of the features of the Grace design that make it especially helpful in an introductory course. I’ll then talk about the head-to-head comparison we ran this fall with the Grace version against a Java version of the same course with parallel texts, assignments, and exams. While we have not yet run a careful statistical analysis of the detailed results, early indications are that Grace is a considerable help to novices in learning.

slides

Robby Findler

slides

Erik Ernst: Reflection Quantification

This talk is about the design of a small embedded DSL, intended to specify the subset of the dynamic semantics of the host language which is supported by mirror based reflection. The main concepts of the DSL are capabilities (concerned with the selection of mirror operations) and annotation (concerned with the selection of host language entities covered by mirrors). The host is the Dart programming language, and the context is the Reflectable package. The toughest balancing act in the design of this DSL was the level of detail: With a detailed level of control the simple usages may be inconveniently verbose to specify, but with a coarse-grained level of control, the larger applications may be forced to have intolerable overhead.

Ross Tate: How Not to Add Type Classes to Type OO Languages

Material-shape separation makes it obvious that typed-OO programmers are naturally dividing their classes and interfaces into types (materials) and type classes (shapes). Material-shape separation also ensures that recursing through types will terminate even when incorporating inheritance. This suggests an obvious solution to adding type classes to OO. Unfortunately, the obvious solution doesn't work. Although it is sound and decidable, it clashes with important usage patterns and OO principles. This is not apparent even after finishing such a design, so in this talk I will illustrate precisely how this solution is surprisingly deceptive.

Martin Odersky: Effects as Implicit Capabilities

It seems obvious that one should track the effects of a piece of code just as one tracks the types of its inputs and outputs. But despite 30 years of research on effect systems, very little of it has been applied in practice, and what was put in practice is sometimes regarded as a failure. A central difficulty is how to express *effect polymorphism*, the ability to write a function once, and to have it interact with arguments that can have arbitrary effects.

I will talk about a new approach to effect checking which has an elegant solution to the effect polymorphism problem and promises to be quite usable in practice. The central idea is that instead of talking about effects we talk about capabilities. For instance, instead of saying a function ``throws an IOException'' we say that the function ``needs the capability to throw an IOException''. Capabilities are modeled as values of some set of capability types. I will talk about two new language features that make this approach attractive.

To cut down on boilerplate, capabilities are passed as implicit parameters to the functions that need them. Implicit parameters make call-site annotations unnecessary, but they still have to be declared just like normal parameters. The new construct of implicit function types makes parameters abstractable and thus eliminates declaration-side boilerplate.

Second, there is one fundamental difference between the usual notions of capabilities and effects: Capabilities can be captured in closures. This means that a capability present at closure construction time can be preserved and accessed when the closure is applied. Effects on the other hand, are temporal: it generally does make a difference whether an effect occurs when a closure is constructed or when it is used. We propose to address this discrepancy by introducing a ``pure function'' type, instances of which are not allowed to close over effect capabilities.

Jens Palsberg: Breaking Through the Normalization Barrier: A Self-Interpreter for F-omega

According to conventional wisdom, a self-interpreter for a strongly normalizing lambda-calculus is impossible. We call this the normalization barrier. The normalization barrier stems from a theorem in computability theory that says that a total universal function for the total computable functions is impossible. I will show how to break through the normalization barrier and define a self-interpreter for a widely used strongly normalizing lambda-calculus. After a careful analysis of the classical theorem, we show that static type checking can exclude the proof's diagonalization gadget and leave open the possibility for a self-interpreter. Our self-interpreter relies on a novel program representation that may be useful in theorem provers and compilers. Joint work with Matt Brown; presented at POPL 2016.

Manuel Serrano: Hop.js

Hop.js is a multitier extension of JavaScript^?. It allows a single JavaScript^? program to describe the client-side and the server-side components of a Web application. Its runtime environment ensures a consistent execution of the application on the server and on the client. This talk will shows its minimal set of JavaScript^? extensions that makes Web programming easier. It will present its runtime environment, with an emphasize on the handling of server-side parallelism.

Crista Lopes: Yet another SQL-OO integration (YASOO) with dependent types and differential computation (YASOO-DT)

I've been working in large-scale, decentralized simulations of urban areas [1], and a problem has come up repeatedly: how to partition the load and how to share data between the partitions. In these kinds of systems, if you are not careful you end up with APIs that don't align well with stakeholders and expert developers and that, therefore, are very painful to develop for. In trying to improve the development process of these simulations, I am converging to a solution that has roots in relational algebra, dependent types and differential computation. It works in the lab! [2]

[1] https://www.youtube.com/user/encitravideos [2] Applicability in the wild is still TBD

Sean McDirmid^?: The past, present, and future of live programming

This talk will present the promise of live programming as I currently see it. Narrowly defined, live programming has been about providing feedback about how a program executes while it is being written by the programmer, combining the phases of debugging and editing for a more fluid feedback loop. However, as Chris Hancock and Bret Victor have pointed out, this really isn’t good enough to move the needle on better programmer experiences. Through multiple demos, I will show what works and what hasn’t worked, and more importantly provide context on why these results occurred. I will then present some future directions for this field.

Andrew Black: The Essence of Inheritance

Programming languages serve a dual purpose: to communicate programs to computers, and to communicate programs to humans. Indeed, it is this dual purpose that makes programming language design a constrained and challenging problem. Inheritance is an essential aspect of that second purpose: it is a tool to improve communication. Humans understand new concepts most readily by first looking at a number of concrete examples, and later abstracting over those examples. The essence of inheritance is that it mirrors this process: it provides a formal mechanism for moving from the concrete to the abstract.

Todd Millstein: Why Do Language Designers Tolerate Weak Memory Consistency Models?

Almost all languages today are memory safe, thereby providing simple and strong guarantees to all programs, buggy or otherwise. Yet the concurrency semantics of these “safe” languages causes similar problems as arise in memory-unsafe languages: small program errors can expose implementation details, violate fundamental language abstractions, and compromise program safety. Why do language designers tolerate this situation? In this talk I’ll overview the state of concurrency semantics as it exists today and argue that safe languages must support sequential consistency (i.e., the interleaving semantics of threads). Along the way I’ll also debunk a few persistent myths.

Michael Greenberg: The POSIX shell as a programming language

We build intricate systems with complex algorithms and invariants, aiming for guarantees of correctness and performance... and then we maintain and deploy these systems with shell scripts! What are shell scripts? If POSIX shell is a programming language, what are its syntax and semantics? Can we apply PL tools to reason about the shell?

Adam Chlipala: A Micro-Tutorial on Multi-Tier Metaprogramming with Ur/Web

One of the unusual features of the Ur/Web programming language is flexible but statically typed generation of web-application code that needs to coordinate across three different tiers: database, web server, and browser. I will demonstrate the main ideas with a simple generic component for adding rows to an SQL database table.

Jonathan Edwards: Transcript: not programming mobile social apps

Transcript is an experiment to radically simplify programming of mobile social applications. We will demonstrate an early prototype and discuss the key design ideas that simplify the programming experience.

Jonathan Aldrich: Achieving Architectural Control via Language Support for Capabilities

Many important architectural properties of software depend on how resources such as storage or the network are used. Unfortunately, today's software architects have few ways to control those resources, other than by leveraging woefully inadequate software processes. We propose to leverage capabilities--unforgeable tokens that control access to resources--to isolate the enforcement of architectural properties to a few critical resource-using modules, on which assurance efforts can be focused. We also present improvements in language support for capabilities, including a non-transitive model of capability-based authority, a capability-aware module system, and design principles for type systems and reflection systems that are compatible with capabilities.

slides

Alessandro Warth: Growing Language Designers

Despite the high caliber of our students, the recurring Programming Language Design Seminar at UCLA did not consistently generate the kind of output we had hoped for. One issue was that students lacked the PL prototyping chops required to do meaningful work in such a short time — 10 weeks fly by when you’re having fun. Last year we created a new class to address this problem. Thanks in part to a novel framework that aims to minimize unnecessary friction and give students “instant gratification” when possible, the new class was a great success and turned out to be much more popular than we anticipated. (Joint work with Todd Millstein and Alan Kay.)

Eelco Visser: The Name Binding Game

In this talk I explore the expressiveness (or lack thereof) of the scope graph framework for encoding the name binding rules of programming languages.

Evan Czaplicki: Type inference and excellent error messages

The last two release of Elm (0.15.1 and 0.16) focused primarily on producing excellent error messages. The conventional wisdom seemed to be "making nice error messages in type inferred languages is not really feasible, so just get used to how things are." This is not a recipe for growing a successful language in the JS world though. As I began exploring this topic I found that you can make enormous practical improvements for your users without anything particularly fancy. I believe the general technique I used in Elm would work just as well in languages with more complex type systems (like OCaml or Haskell) as long as they use a constraint-based solver.

Heather Miller: Distributed programming via safe closure passing

Scala is a popular implementation language of big data frameworks. Leading frameworks like Spark and Kafka have nodded their hats to Scala, noting that some of their ability to innovate were provided by aspects of Scala’s mixed object-functional design, such as its support for first-class functions. However, problems abound; function closures in Scala weren’t designed with the idea of them being serialized and sent over the wire in mind, resulting in end-user headaches across frameworks. We proposed a solution to the closure serialization problem with spores, a refinement to functions in Scala that make closures more reliable to serialize. I'll discuss ongoing work on a programming model we have built atop of spores which aims to generalize models like MapReduce^? by enabling a more principled way to move "functionality" to immutable data spread across a network.

Jan-Willem Maessen:

slides

• Dates: October 3-7, October 2016
• Venue: EPFL, Lausanne, Switzerland
• Host: Heather Miller

Program

The meeting starts on Monday morning October 3 at 9AM and ends with lunch on Friday October 7.

The program consists of a series of 50 minute sessions, which are scheduled during the meeting. In each session the speaker gets 25 minutes to present and the audience gets 25 minutes to discuss, in no particular order (although we tend to give the presenter a couple of minutes to at least introduce the topic). Time is administered using a chess clock. (If attendance is high we may have to reduce session times somewhat.)

Prospective speakers are invited to send a talk proposal including title and abstract to the chair (Eelco Visser).

Venue

The meeting will take place at EPFL, in the BC building, room BC410

The meeting room is situated on the top floor of building BC, one of EPFL's main computer science buildings which boasts ample seating and meeting space and a large terrace with stunning views of Lake Geneva and the Alps. Lunches will be provided in an on campus cafeteria at EPFL, and afternoon coffee and snacks will also be provided in the meeting room area. Wifi will be available via the campus guest network or eduroam, and a cafeteria is just a few steps away where an assortment of drinks, coffee, and snacks are available throughout the day for sale.

Getting There

The nearest airport is the Geneva airport (GVA) a well-connected mid-size international airport with many nonstop long-haul flights arriving/departing daily. The Geneva airport is about a 40 minute train/metro ride from EPFL. One can take a direct train from the train station at the Geneva airport to Lausanne or Renens, from there, EPFL is just a short metro ride away.

Another large and well-connected Swiss airport is the Zurich airport (ZRH) which serves more long-haul destinations nonstop than the Geneva airport. The Zurich airport is about 2.5 hours by train from Lausanne, and can be worth the trip for a convenient nonstop itinerary. One can take a direct train from the Zurich airport to the Lausanne train station, and from there, EPFL is just a short metro ride away.

Accommodation

We have booked a block of 20 rooms in the SwissTech Hotel, a new, modern hotel that is minimal, comfortable, and affordable, and only 5-10 minutes by foot from the meeting room at EPFL. Our group rate is 120CHF/night (~$120) which is quite affordable for Lausanne.

If you're interested in taking one of these rooms, you must claim and pay for your room by September 1, 2016. Contact Heather (heather.miller@epfl.ch) to get the ball rolling (rooms are first come, first serve!)

Else, there are many other hotels in the city center of Lausanne, situated ~20 minutes via public transit from EPFL. Affordable hotels include: LHotel Flon, Hotel Ibis Lausanne Centre, and the Swiss Wine Hotel. If staying in one of these hotels, budget at least 30 minutes for the commute to EPFL in the mornings.

Note that all guests of a Lausanne hotel receive free public transport cards good for all forms of public transit in Lausanne.

* Booking: online via http://www.swisstech-hotel.com, must use booking code: WG216

Registration

Registration is required, however fees will be collected during or after the meeting. Registration is planned to cost $225. Included in the registration fee is lunches on all days, coffee/snacks during the afternoon coffee breaks, and all group dinners.

To register, please fill out the registration form.

Participants

Organization

• Eelco Visser (Chair)
• Tijs van der Storm (Vice Chair)
• Jonathan Edwards (Secretary)
• Heather Miller (Local Organizer)

Members

• Adam Chlipala
• Daan Leijen
• Jan-Willem Maessen
• Mark S. Miller
• Yannis Smaragdakis
• Roberto Ierusalimschy
• Jonathan Aldrich
• Klaus Ostermann
• Edwin Brady
• Markus Voelter
• Manuel Serrano

Visitors

• Michael Greenberg
• Martin Odersky
• Francois Pottier
• Luke Church
• James Larus

Monday

• Chair's opening
• Brief round of introductions: just your name and affiliation are fine
• Local organizer's instructions

• talks tba

Tuesday

• talks tba

Wednesday

• talks tba

• Excursion in the afternoon

Thursday

• talks tba
• Business meeting

Friday

• talks tba

Talks

Yannis Smaragdakis: My Foray Into Declarative Languages

• Dates: August 28 - September 1, 2017
• Venue: Park City, Utah, USA
• Host: Matthew Flatt

https://www.flickr.com/photos/tkellyphoto/6246702517

Venue

The meeting will take place at the Treasure Mountain Inn in Park City, Utah. Park City is best known as a ski destination and as the home of the Sundance Film Festival. Tourists also visit in the summer, but late August will be uncrowded.

See Accommodations below for information on booking a room at the group rate in the meeting hotel.

Getting There

Fly to Salt Lake International Airport (SLC). Park City is about 40 minutes from the airport by car or shuttle. All Resort is a popular shuttle service, or see visitparkcity.com. The hotel recommends Express for Less (435-649-8999).

A shuttle typically costs $40 one way. A taxi or private car will easily be twice that. Renting a car from the airport is convenient and likely to be cheaper if 2 or more people carpool. The hotel provides parking, and you won't need a car in Park City itself, since the hotel is right on Main Street and surrounded by restaurants, shops, and mountains, but you can get to even better outdoor activities with a short drive into the mountains.

Coordination and Registration

Please fill out this form to let the organizers know that you will attend and to get help coordinating transportation and/or accommodations.

The registration fee will cover the meeting room, coffee/tea during the meeting, all lunches, and all dinners. The fee will be collected at the end of the meeting based on actual costs, expected to be $325 per person.

Accommodations

Contract Treasure Mountain Inn through the web site or by phone to make a reservation.

We originally had a group rate of $126/night single occupancy, $146/night double occupancy, but the hotel is now under new management, and the normal advertised rates have been cheaper than that.

Note that the room options include a two-bedroom suite, so consider rooming with another participant to reduce costs.

Schedule

The meeting will start at 8:45am on Monday, August 28 and continue through lunchtime on Friday, September 1. We plan a hiking excursion into the surrounding mountains on Wednesday after lunch.

• Monday lunch: Blue Iguana at noon
• Monday dinner: Vinto at 6:00pm; see VintoGroupMenuMeeting2017

• Tuesday lunch: Shabu at noon
• Tuesday dinner: 501 on Main at 6:30pm

• Wednesday lunch: The Bridge Cafe & Grill at noon
• Wednesday dinner: 710 Bodega at 7:00pm

• Thursday lunch: Bistro 412 at noon; place order
• Thursday dinner: Bangkok Thai at 6:00pm

• Friday lunch: Wasatch Brew Pub at noon

Participants

Organizers

• Matthew Flatt (local organizer)
• Eelco Visser (chair)
• Jonathan Edwards (secretary)

Members

• Manuel Serrano
• Jan-Willem Maessen
• Adam Chlipala
• Kim Bruce
• Ross Tate
• Tom Van Cutsem
• Yannis Smaragdakis
• Daan Leijen
• Robby Findler

Visitors

• John Regehr
• Eric Eide
• Luke Church
• Matthias Hauswirth
• Nada Amin
• Heather Miller
• Emerson Murphy-Hill
• Éric Tanter
• Michael Greenberg

Monday

• Adam Chlipala
• Kim Bruce (Slides)
• Jonathan Edwards

• Robby Findler
• Yannis Smaragdakis (Slides)
• Tom van Cutsem

Tuesday

• Nada Amin
• Emerson Murphy-Hill
• Eric Tanter

• Luke Church
• Matthias Hauswirth
• Michael Greenberg

Wednesday

• Eric Eide
• John Regehr
• Tom van Cutsem

Excursion in the afternoon

Thursday

• Heather Miller (Slides)
• Manuel Serrano
• Eelco Visser (Slides)

• Daan Leijen
• Ross Tate
• Business Meeting

Friday

• Matthew Flatt
• Jan-Willem Maessen (Slides)
• Manuel Serrano, Robby Findler: Esterel

Abstracts

Robby Findler: Racket and Language-oriented Programming

...

Jonathan Edwards: Reifying Programming

The need to think abstractly makes programming difficult, especially for normal people. To make programming more concrete I propose to represent programs as data structures reifying their execution. Programming shifts from editing textual abstractions to direct inspection and manipulation of concrete executions. Reified execution also helps ground abstraction through a new testing mechanism: interventions. An intervention tests and overrides behavior at a specific point within a reified execution, replacing hand-coded tests and mocks. Intervention points are stable because programs are edited structurally, not textually. Interventions also provide scaffolding that assists program development through refactoring-like steps of gradual abstraction.

Matthias Hauswirth: Abstraction-Free Programming

Abstraction is probably the most important idea in programming. However, many people have difficulties with abstract thinking. If we want to teach programming to all, could we do so without requiring abstract thinking? In this this talk we discuss this question and propose three abstraction-free programming "languages" that might help to provide an initial programming experience for people without abstraction skills. We hope to get feedback on our three language ideas and spark a discussion about abstraction and programming in general.

Michael Greenberg: Kleene algebra modulo theories

Are you working on something that can be modeled in terms of simple While programs over some decidable domain? Kleene algebra modulo theories (KMT) is a pay-as-you-go approach for sound, complete, and decidable models of simple programs. The KMT metatheory corresponds directly to an automata-theoretic implementation strategy: for just a few lines of code describing your theory’s syntax and decision procedure, we can decide equivalences in While programs over your theory.

Yannis Smaragdakis: Languages for Large Productivity Gains: What Will they Look Like?

In the past decade, I've worked a lot with (and on) declarative languages. I'll use this experience as a basis to discuss what a high-productivity language of the future (or the present!) might look like. This is a continuation of my Lausanne meeting talk, with more emphasis on the lessons learned. I will argue that a high-productivity language a) will have implementations capable of large performance gains (i.e., the difference between optimized and unoptimized performance will be asymptotically large); b) will need strict limits (such as termination or logical monotonicity) to preserve a reasonable programming model; c) will change development patterns often taken for granted.

Tom van Cutsem: Machine learning and software development: what does the future hold?

I would love to allocate some time for a discussion about how recent advances in machine learning and AI will (or will not) affect programming languages and software development in general. I can prepare a 10-minute introduction to the topic, highlighting a few interesting ideas I've seen recently where people have started to apply AI techniques to software development and programming. For example, Microsoft research recently published a paper where they've trained a neural network to learn to write code. After the intro, I can then act as a moderator for the rest of the discussion. The idea is to discuss long-term trends, not technical details of specific ideas.

Tom van Cutsem: XStream: declarative authoring of distributed, elastic stream processing pipelines

In this talk I will present XStream, a DSL for writing stream processing queries that are to be executed across distributed network nodes. XStream is used in a stream processing system developed at Nokia Bell Labs to do real-time processing of data and media streams. I will briefly discuss the DSL and how queries get compiled. XStream started off as an external DSL but was later revised to become an embedded DSL. I will recount some lessons learned which are pertinent to language design in an industrial research context in general.

Kim Bruce: Exploring the inheritance design space with Grace

Inheritance and delegation are the two most popular ways of modifying classes and objects to create new objects. Delegation is often used with object-based languages, while inheritance is generally the choice with class-based languages. However while investigating how to include inheritance in Grace, we discovered that there are many subtle differences in defining these notions, and many subtleties that can reach out to bite you. In this talk we explore the design space, and discuss how we chose to support inheritance in Grace.

Emerson Murphy-Hill: What Do Blind Developers Need in a Programming Language?

People who are blind use mainstream programming languages and environments to develop software, but a variety of usability challenges impact them disproportionately and require awkward workarounds. In this talk, I'll discuss what those challenges are, describe some preliminary design criteria for a programming language that overcomes those challenges, and ask for audience suggestions about how we can make progress on this problem.

Daan Leijen: Structured Asynchrony with Algebraic Effects

Algebraic effect handlers generalize many control-flow abstractions that are implemented specially in most languages, like exception handling, iterators, or backtracking. In this article, we show how we can implement full support for asynchronous programming as a library using just algebraic effect handlers. The consistent type driven approach also leads naturally to powerful abstractions like block-scoped interleaving, cancellation, and timeout’s that are lacking in other major asynchronous frameworks. We also introduce the concept of ambient state to reason about state that is local to the current strand of asynchronous execution

https://www.microsoft.com/en-us/research/publication/structured-asynchrony-algebraic-effects

Manuel Serrano: Optimistic JavaScript^? AOT Compilation

JavaScript^? has escaped web pages. It is now also used for programming web servers, compilers, and other general purpose tasks. There is even a growing trend for using it for programming embedded devices. In this context, JIT compilation is ineffective because it is too memory demanding, and interpretation is too slow for anything else but simplistic tasks. Static compilation, //a.k.a.//, ahead-of-time (AOT) compilation, is an alternative approach that can combine the good speed of JIT compilers and the lightweight memory footprint of interpreters.

We have designed an AOT compiler for full-fledged JavaScript^?. It relies on a genuine type analysis called //hint typing//. Contrary to most approaches, hint typing does not infer types according to the data structures the program manipulates but according to the best code the compiler is able to generate. In this presentation, we will present this analysis and the overall architecture of the compiler.

Adam Chlipala: Correct-by-Construction Code Generation for Elliptic-Curve Cryptography

Cryptography libraries make up some of the most important high-performance code. Every SSL-based Web connection involves a suite of algorithms carefully designed for performance. These crucial functions are even commonly handcoded in assembly by the experts -- of which there are only a handful on the planet with the required skills. Many cryptographic algorithms manipulate large integers with modular arithmetic. A change so seemingly trivial as picking a different large prime modulus for an existing algorithm leads, in practice, to one of these experts spending months rewriting and retesting the assembly code from scratch.

I will present our Fiat Cryptography project, which generates new implementations automatically, specifically for the domain of elliptic-curve cryptography. Even better, our framework is a Coq library, and we generate correctness proofs, too. The results are performance-competitive, coming within about 3X (and shrinking, as we add optimizations) of the latency of world-champion implementations written by hand. We use a combination of traditional verification, partial evaluation, and certified compilation. At the center of the framework is a library for big-integer arithmetic, parametrized by a vocabulary of available data structures. Different prime moduli get the best performance with different data structures, and we prove correctness of the core arithmetic operations for all data structures in our parameter space.

This is joint work with Andres Erbsen, Jason Gross, Jade Philipoom, and Robert Sloan.

Nada Amin: Collapsing Towers of Interpreters

Abstract: Given a tower of interpreters, i.e. a sequence of interpreters interpreting each other, we aim to collapse this tower into a one-pass compiler that removes all interpretive overhead. We present a multi-level lambda calculus that features staging constructs and stage polymorphism: based on runtime parameters, the interpreter can either act as a normal interpreter or generate code, which turns it into a compiler, according to the Futamura projections. We identify stage polymorphism as the key mechanism to make such interpreters compose in a collapsible way.

We present a meta-circular Lisp interpreter on top of this calculus and demonstrate that we can collapse arbitrarily many levels of self-interpretation, including levels with semantic modifications. We discuss several examples: compiling regular expressions through a Lisp interpreter to base code, building program transformers from modified interpreters, and others. We develop these ideas further into an implementation of the reflective language Black, which implements a conceptually infinite tower, where every aspect of the semantics can change dynamically, and as a novel feature, we demonstrate how user programs can be compiled and recompiled under user-modified semantics

Éric Tanter: Designing Gradual Languages

Gradualizing type systems often involves a lot of guesswork. Based on an understanding of gradual types as abstractions of static types, we have developed systematic foundations for gradual typing based on abstract interpretation. This talk reports on recent work in applying this approach to a number of typing disciplines. In particular, we highlight the value of Galois connections in gradual language design, and identify open research questions.

Eelco Visser: The Semantics of Name Resolution in Grace

Grace is a dynamic object oriented programming language designed to aid programming education. We present a for- mal model of and give an operational semantics for its object model and name resolution algorithm. Our main contribu- tions are a systematic model of Grace’s name resolution using scope graphs, relating linguistic features to other languages, and an operationalization of this model in the form of an operational semantics which is readable and executable. The semantics are extensively tested against a reference Grace implementation.

This is joint work with Vlad Vergu and Michiel Haisma

Luke Church: A metaphysical turn for designing programming experiences?

There are a variety of techniques for analysing the design of programming experiences; how these techniques relate to each other has become a contentious issue. To help illuminate the problem we report the findings of in depth interviews with 20+ staff involved in the evolution of Dart, how they reason about changes to the language and what they would like to know.

From this pragmatic grounding, we introduce the notion of 'analytical distance' as a way of talking about the various techniques available. This highlights a major gap between what designers what to know and what our existing techniques can tell them. We speculate that adopting a metaphysical stance on programming language usability might help address this gap.

Eric Eide: A DSL for Secure Cloud-based Collaboration

Despite advances in cloud security, cloud tenants remain vulnerable to network-based attacks. IP networks allow devices to communicate by default, and restrictions imposed by firewalls tend to be coarse-grained, largely static, and centrally administered. What if the network instead followed the principle of least privilege and allowed tenants to dynamically craft just the communication policies they need? In this talk I will describe a DSL that aims to strengthen the network security of cloud tenants and multi-tenant collaborations. A variant of this DSL has been implemented in a system called CapNet^?, but it remains a work in progress. For example, the DSL does not yet address DPI, QoS^?, or routing concerns. It also does not yet account for collaborations between tenants in separately administered clouds. These and other extensions of the DSL are unresolved language-design challenges.

Matthew Flatt: Designing a Language for Cognitive-Science Experiments

In a typical experiment to test a cognitive-science hypothesis, a human subject receives a sequence of stimuli, where each stimulus's properties are determined by a number of experimenter-selected factors (e.g., color, shape, word). In simple experiments, each subject can see all possible combinations of factors, and a statistical analysis of the results is relatively straightforward. When the number of possible combinations becomes too large for a simple crossing of all possibilities, or when the relative order of different combinations of factors is relevant to the hypothesis under test, then choosing a set of stimuli to obtain statistically useful results can be more difficult.

In those more difficult cases, experimenters mostly write ad hoc scripts to generate the stimuli for an experiment. Bugs in the scripts --- either in the code or the ad-hoc approach used to generate combinations --- can mean that effort is wasted on experiments that cover a statistically inclusive range. We are designing a language for experiment design that generalizes a basic model of factors and crossings and adds new constructs to impose constraints on the generated stimuli. A key problem in the implementation is choosing uniformly from the distribution of stimuli that satisfy the constraints; recent work on uniform sampling of SAT formulae seems to be exactly the tool we need, and we target that tool in the design of our constraint language.

Heather Miller: A Programming Model and Foundation for Lineage-Based Distributed Computation

The most successful systems for “big data” processing have all adopted functional APIs. We present a new programming model we call "function passing" designed to provide a more principled substrate, or middleware, upon which to build data-centric distributed systems like Spark. A key idea is to build up a persistent functional data structure representing transformations on distributed immutable data by passing well-typed serializable functions over the wire and applying them to this distributed data. Thus, the function passing model can be thought of as a persistent functional data structure that is distributed, where transformations performed on distributed data are stored in its nodes rather than the distributed data itself. One advantage of this model is that failure recovery is simplified by design–data can be recovered by replaying function applications atop immutable data loaded from stable storage. Deferred evaluation is also central to our model; by incorporating deferred evaluation into our design only at the point of initiating network communication, the function passing model remains easy to reason about while remaining efficient in time and memory. Moreover, we provide a complete formalization of the programming model in order to study the foundations of lineage-based distributed computation. In particular, we develop a theory of safe, mobile lineages based on a subject reduction theorem for a typed core language. Furthermore, we formalize a progress theorem which guarantees the finite materialization of remote, lineage-based data. Thus, the formal model may serve as a basis for further developments of the theory of data-centric distributed programming, including aspects such as fault tolerance.

John Regehr: Superoptimizing LLVM

LLVM serves as an intermediate representation between several programming languages and a number of target architectures. Although LLVM already supports many IR-level optimizations, plenty of optimizations have not yet been implemented. I'll talk about Souper, a superoptimizer that automatically synthesizes new optimizations for LLVM. Souper can also interact with some of LLVM's dataflow analyses, both learning from them and finding situations where their precision can be improved.

Ross Tate: Discussion on Method Overloading

Method overloading is a feature of many major programming languages, one which people have strong and varied opinions about. Rather than give a talk on overloading, I will conduct a discussion to collect together our experiences with this topic. The goal is not to decide whether method overloading is good or bad, although hopefully from this discussion we will all gain a broader understanding of the topic. Rather, the goal beyond this collection is to identify potential avenues for variations of method overloading that may achieve much of what a designer might value in overloading while avoiding the many pitfalls of overloading that a designer may or may not be aware of.

Jan-Willem Maessen: Derivatives, CPS, Defunctionalization, And Machine Learning (Slides)

In machine learning, extensive use is made of reverse-mode automatic differentiation to compute the gradient of model parameters with respect to the value of a fitness function. This is typically done using a "tape" model that logs forward operations and their results. In our Athens meeting I got interested in the relationship between data type derivatives and defunctionalized CPS transformations – we can connect the reified stack of our computations to data structures describing the call structure of the program. This gives us the opportunity to incrementalize computation and turn recursion into iteration in a very general setting. Talking to Alex Woltzko at Google, it appears there may be deep connections between the data capture performed by automatic differentiation and the data structures of recursion removal. I'll talk about my early explorations, and then broaden the discussion to opportunities for PL designers to collaborate in machine learning research.

• Dates: May 14-18, 2018
• Venue: Antwerp, Belgium
• Host: Tom Van Cutsem

https://lonelyplanetimages.imgix.net/mastheads/GettyImages-486812737_super.jpg

Slides

The slides of many of the talks are now available in the table at the bottom of this page.

Program

The meeting starts on Monday morning May 14th at 9AM and ends with lunch on Friday May 18th.

The program consists of a series of 50 minute sessions, which are scheduled during the meeting. In each session the speaker gets 25 minutes to present and the audience gets 25 minutes to discuss, in no particular order (although we tend to give the presenter a couple of minutes to at least introduce the topic). Time is administered using a chess clock. (If attendance is high we may have to reduce session times somewhat.)

Prospective speakers are invited to send a talk proposal including title and abstract to the chair (Eelco Visser).

Venue

The meeting will take place in Antwerp, Belgium in the offices of Nokia Bell Labs.

The offices are conveniently located right next to Antwerp Central railway station and a 10-minute walk from the city centre.

Address: Nokia Bell, Copernicuslaan 50, 2018 Antwerp, Belgium (Map). (please note: main entrance is on the Kievitplein, a pedestrian-only square, not in Copernicuslaan. The entrance is clearly marked with a big NOKIA sign.)

On the first day, please register at Reception through the main entrance (mention WGLD meeting with Tom Van Cutsem) and wait until someone comes to fetch you.

We will be meeting in Nokia building C, 11th floor, room C11-Tim Berners-Lee.

Getting There

Fly into either Brussels National Airport (BRU) or Amsterdam Schiphol Airport (AMS). Brussels is closer to the final destination, but Amsterdam has more direct long-haul flights.

From Brussels airport, the easiest option is to simply take a local train from the Brussels airport train station to Antwerp Central station. There's a direct connection that should get you from the airport into Antwerp in about 30 minutes (no upfront seat reservation required). The meeting venue is located right next to Antwerp's Central station.

From Amsterdam Schiphol airport, there is also a direct train service to Antwerp. You can either take a local commuter train (no upfront seat reservation required) which should get you there in about 2 hours, or take a high-speed train (Thalys) which will get you there in 56 minutes. Thalys trains require upfront seat reservation.

For train time tables and tickets, see the website of the Belgian national railway service NMBS.

Detailed instructions for getting to the Nokia Bell Labs Antwerp offices, including some sightseeing highlights, can be found in this leaflet.

Accommodation

The Lindner Hotel is located right next to Nokia's offices.

A block of 20 rooms has been reserved for us at discounted rates until April 15, 2018. These are economy class single rooms, at the Nokia rate of EUR 109 per night (including breakfast, excluding EUR2.39 tourist tax).

To book a room, send a mail to reservations.antwerpen@lindnerhotels.be and mention the following:

• Reservation code "WGLD", block ID. 8819749.
• Your Name
• Check-in and check-out date
• Credit card info

You will get a confirmation through e-mail.

Reservation at the discounted rates in the Lindner Hotel is possible until April 15.

An alternative option is the Leopold Hotel, just a 5-minute walk from the Nokia offices. The rate for this hotel is EUR 102 per night (including breakfast, excluding EUR2.39 tourist tax). To make a reservation, send mail to res.antwerp@leopoldhotels.com stating that you are a visitor at Nokia and would like to receive the Nokia rate.

A more budget-friendly option also within short walking distance is the Ibis Hotel Antwerp Central station. Nokia does not have a special rate, so you can just book online.

Registration

Registration is required so that we can take care of logistics. Please fill in this registration form (note: registrations are closed. Please send mail to Tom Van Cutsem to make updates to your registration)

A registration fee of EUR 250 will be due 1 month prior to the start of the meeting. This fee will cover use of the meeting room, coffee breaks Mon-Fri, lunches Mon-Fri, dinners Mon-Thu and a social event on Wed afternoon. Payment details will be sent out separately.

Schedule

Meetings will start at 9AM and end around 5-5.30PM.

Lunches and coffee breaks will be on-site.

• Monday Dinner: 6.30PM at Lindner Hotel, Lange kievitstraat 125, Antwerp (just across the street from venue)
• Tuesday Dinner: 6.30PM at Wagamama, De Keyserlei 13, Antwerp (10 minute walk from venue)
• Wednesday Dinner: 7PM at Felix Pakhuis, Godefriduskaai 30, Antwerp (30 minute walk from venue, or take bus)
• Thursday Dinner: 7PM at Gran Duca, De Keyserlei 28, Antwerp (10 minute walk from venue)

Participants

Organizers

• Tom van Cutsem (local organizer)
• Eelco Visser (chair)
• Tijs van der Storm (vice-chair)
• Jonathan Edwards (secretary)

Members

• William Cook
• Klaus Ostermann
• Markus Voelter
• Roberto Ierusalimschy
• Jan-Willem Maessen
• Luke Church
• Edwin Brady
• Andrew Black
• James Noble
• Erik Ernst
• Klaus Ostermann

Visitors

• Nada Amin
• Matthias Hauswirth
• Éric Tanter
• Ronald Garcia
• Jan Vitek
• Stefan Marr
• François Pottier
• Elisa Gonzalez Boix
• Sylvan Clebsch

Program

Monday

• Jonathan Edwards
• Roberto Ierusalimschy
• Eelco Visser

• Tijs van der Storm
• Markus Voelter
• Andrew Black

Tuesday

• Jan Vitek
• Ronald Garcia
• Stefan Marr

• Francois Pottier
• Eric Tanter
• Matthias Hauswirth

Wednesday

• Klaus Ostermann
• Sylvan Clebsch
• William Cook

Excursion in the afternoon

Thursday

• Elisa Gonzalez Boix
• Jan-Willem Maessen
• Luke Church

• Nada Amin
• Erik Ernst
• Business Meeting

Friday

• Tom van Cutsem
• James Noble

Talk abstracts

Markus Voelter: A spreadsheet extension for KernelF

As we all (sometimes slightly jealously) acknowledge, spreadsheets are used widely for "programming", especially by the domain-experts we often want to convince of DSLs. We also all agree about the limitations of spreadsheets in terms the error-proneness of large, intricate sheets.

Essentially, spreadsheets represent functional programs that are executed reactively, whenever a user changes the contents of a cell. This makes them fit well with functional programming in general.

In this talk I present a prototypical extension of the KernelF^? functional programming language that supports spreadsheets. I briefly introduce KernelF^?, discuss the motivation for building the spreadsheet extension and then demonstrate how it fits in with KernelF^?'s functional paradigm.

We have also made several extensions of the spreadsheet paradigm that aim at fixing some of the problems observed in spreadsheets. I will introduce those, and hope to get feedback on other ideas we could

Eelco Visser: The Syntax Definition Formalism SDF3

I describe the design of the syntax definition formalism SDF3 by means of propositions that capture its concepts.

Andrew P. Black: Design Principles for 
the Grace AST

Grace dialects can restrict the dialectic language by writing a tree-walker for the AST that restricts allowable programs (compared to standard Grace). As a consequence, the Grace language definition must include a definition of an AST for Grace.

What are the requirements on such an AST? Can we come up with “Design Principles” for an AST to guide us in its design? How do we know when the AST is adequate? Or when it is overspecified? What is an AST, anyway?

Now that there are multiple implementations of Grace, it is time to face these questions. I don’t have many answers, but hope that the combined expertise of the working group will help us find some.

Roberto Ierusalimschy: The Titan Programming Language

The Titan Programming Language: a statically typed companion language to Lua, designed for writing applications and libraries, with performance in mind.

Jonathan Edwards: Direct Programming

To make programming more concrete I am taking another run at the old ideas of macro recording and Programming by Example. Many such efforts abstracted user actions into conventional code. Instead I co-design the PL and UI to be analogous, so that programs and users have the same capabilities, and programs look much like recorded transcripts of user actions. This correspondence may aid beginning programmers. Another benefit is that programs can not only be abstracted from user actions but also be incrementally revised through further actions.

Any attempt to make programming more concrete must overcome two main obstacles: loops and conditionals, for they deal with hypothetical situations. My approach is to extend the direct manipulation metaphor onto template states that prototype iteration, and example states that witness alternative cases.

Jan Vitek: The Beauty and the Beast — from Fortress to Julia

Take two languages, Julia and Fortress, designed to solve similar problems with similar mechanisms and compare the approaches that led to one to being adopted and the other discontinued. What lessons are there for language designers? Can the designs be reconciled? Can we somehow turn the beast that is into the beauty that could have been? This talk is a snapshot of our investigations into Julia with more open questions than definitive answers. Julia’ design is a pragmatic effort driven by use-cases and user feedback. In contrast, Fortress followed a principled, formally grounded, approach that aimed for type soundness first. We will marvel at the efficacy of Julia's compiler -- a one-trick pony that works well in practice. We will inspect the multi-dispatch feature of Julia and puzzle at the subtype relation that is at its heart. The takeaway of the talk is a list of language features that are key to performance and usability.

Ronald Garcia: Type-driven Gradual Security Typing

Information-flow security-typed programming languages use types to statically enforce noninterference between potentially conspiring values, such as the arguments and results of functions. But to adopt static security types, like other advanced type disciplines, programmers must adopt the discipline wholesale.

To provide a gentler path to security typing, researchers have designed languages that blend static and dynamic checking of security types. Unfortunately most of these languages support static, type-based reasoning about noninterference if programs are entirely statically secured. This limitation substantially weakens the benefits that dynamic enforcement brings to static security typing.

This talk describes GSLref, a security-typed higher-order language that supports gradual migration between a simple type discipline and security type discipline, using the principles underlying gradual typing.

GSLref satisfies most of the criteria set forth by Siek et al. for gradually-typed languages. The one exception, called the "dynamic gradual guarantee" cannot be satisfied without violating noninterference.

To realize this design, we were led to draw a sharp distinction between syntactic type safety and semantic type soundness, each of which constrains the design of the gradual language.

Stefan Marr: Designing Small and Versatile Collection Libraries: Providing an Efficient and Thread-Safe Implementation

Collection libraries differ significantly between languages, but there are some indications that we could make do for most use cases simply with sequence, map, and set collections. Modern dynamic languages show this form of minimalism and compensate by making their collections highly versatile. For instance, an array is usually dynamically sized and provides operations to act as queue, dequeue, or stack. However, this design comes with implementation challenges and dynamic language implementations apply various optimizations to make it efficient.

So far, these optimizations have been one of the reasons that languages such as Ruby and Python do not yet have implementations that are efficient and allow parallel execution while providing a thread-safe implementation that does not expose any races from the VM implementation to the language.

This talk presents a technique to ensure implementation-level thread-safety for such collections. With it, we enable an idiomatic dynamic language programming style for parallel code. In practice this means, VMs do not need a global interpreter lock to guarantee safety while avoiding to compromise single-threaded execution performance.

Matthias Hauswirth: Misconceptions & PL Design

Programming languages are conceptually dense constructions. Expressing a program in a given language requires an accurate understanding of the concepts of that language. A programmer’s misconceptions about a language eventually lead to incorrect programs.

In this talk I will give a brief introduction to an area of the learning sciences focusing on human conceptions, misconceptions, and conceptual change. I will then try to connect these ideas to programming language design. My goal with this talk is to trigger discussions on PL design and evaluation by stepping outside the normal PL design zone.

Klaus Ostermann: Dualizing Generalized Algebraic Data Types by Matrix Transposition

We characterize the relation between generalized algebraic datatypes (GADTs) with pattern matching on their constructors one hand, and generalized algebraic co-datatypes (GAcoDTs^?) with copattern matching on their destructors on the other hand: GADTs can be converted mechanically to GAcoDTs^? by refunctionalization, GAcoDTs^? can be converted mechanically to GADTs by defunctionalization, and both defunctionalization and refunctionalization correspond to a transposition of the matrix in which the equations for each constructor/destructor pair of the (co-)datatype are organized. We have defined a calculus, GADT^T, which unifies GADTs and GAcoDTs^? in such a way that GADTs and GAcoDTs^? are merely different ways to partition the program.

We have formalized the type system and operational semantics of GADT^T in the Coq proof assistant and have mechanically verified the following results: 1) The type system of \ourlang{} is sound, 2) defunctionalization and refunctionalization can translate GADTs to GAcoDTs^? and back, 3) both transformations are type- and semantics-preserving and are inverses of each other, 4) (co-)datatypes can be represented by matrices in such a way the aforementioned transformations correspond to matrix transposition, 5) GADTs are extensible in an exactly dual way to GAcoDTs^?; we thereby clarify folklore knowledge about the ``expression problem''.

We believe that the identification of this relationship can guide future language design of ``dual features'' for data and codata.

This talk is based on joint work with Julian Jabs.

Eric Tanter: Gradual Parametricity, Revisited

Bringing the benefits of gradual typing to a language with parametric polymorphism like System F, while preserving relational parametricity, has proven extremely challenging: first attempts were formulated almost a decade ago, and several recent developments have been published in the past year. On the one hand, the different forces at play have led researchers to propose language designs with varying goals and compromises, with sometimes surprising consequences. On the other hand, the complexity of the technical details has resulted in several important results to remain stated as conjectures. In this work, we first identify a crucial, yet ignored, property of a language with gradual parametricity, which turns out to be violated by all prior work. This observation suggests that existing cast calculi are not well suited for supporting a gradual version of System F. We then formulate clear design goals for a gradual language with explicit parametric polymorphism, GSF, and explore to which extent the Abstracting Gradual Typing methodology helps us derive such a language. GSF satisfies all the expected properties, save for one property—the dynamic gradual guarantee—which was left as conjecture in all prior work. Here, we prove that this property is simply incompatible with parametricity, unless one is willing to adjust accepted definitions. This situation, reminiscent of recent results on gradual noninterference, reinforces the view that new criteria might be needed to characterize the spectrum of type-based reasoning that gradual typing supports when applied to semantically-rich disciplines.

William Cook: Rethinking Excel in Enso

I’m trying to rethink Excel to eliminate repeated but slightly different equations, and have a secure approach to editing rows and columns, so that equations are always correctly defined. I have two sample Excel applications: one involving grades (normalizing them, curving them, combining them, etc), and one involving work scheduling, but the idea changing Excel to have a Data Model, Computation Model, and a Presentation model, is generally appealing. The question is how to design the modeling languages to work together and implement an engine that can let users view the models as a grid (or other views), while editing at multiple different levels. I need some help with my presentation model.

Luke Church: Entangling intelligences

I present work at Lark Systems, integrating together different types of thinking and the way these affect the way people program.

Francois Pottier

Reachability and error diagnosis in LR(1) parsers

Contrary to an ill-advised folklore myth, an LR(1) parser can produce good syntax error messages. In fact, an LR(1) parser generator can build a collection of erroneous input sentences that covers every “error state”, that is, every state of the LR automaton in which an error might be detected. This feature can be exploited by a grammar designer to examine each such state and either (a) propose a handwritten diagnostic message for this state, or (b) modify the grammar and/or the automaton so that this error state disappears. I report on an application of this technique to the CompCert^? ISO C99 parser, and discuss its strengths and limitations. (This work was presented at CC 2016.)

and the visitors talk:

Visitors Unchained

Traversing and transforming abstract syntax trees that involve name binding is notoriously difficult to do in a correct, concise, modular, customizable manner. I address this problem in the setting of OCaml, a functional programming language equipped with powerful object-oriented features, using visitor classes as partial, composable descriptions of the operations that we wish to perform on abstract syntax trees. (This work was presented at ICFP 2017.)

Sylvan Clebsch: Language Runtimes for Parallel Programming: Weak Memory and Program Order

Language runtimes notoriously involve frantic bit twiddling, very fine grained atomic operations, and a reliance on the specific behaviour of particular architectural targets. How do we know our code implements our intended memory model? How do we know our memory model maps, and maps efficiently, to the hardware memory model? What is “program order” when we need interleaved and independent “happens before” guarantees? What is the type of a range of memory reserved by the memory allocator before it has been committed, or after it has been freed by the language? Perhaps we need a low-level systems language for writing runtimes that treats “happens before” as a core building block.

Jan-Willem Maessen: Confessions of a Reluctant Imperative Programmer

I consider myself a functional programmer who happens to do a lot of systems programming in non-functional languages. But the imperative style of control flow – loops with break and continue, functions with intermediate return, local variables that can be re-bound – is in many cases easier for me as a programmer to read and write than the equivalent code in a typical functional language. Why is this? And when does it break down? I'll end with some questions about how we might do better.

Tom van Cutsem: Control flow goodness in modern JavaScript^?

A whirlwind tour of JavaScript^?’s most recently added control flow constructs: promises, iterators, generators and async functions.

• "You always have the choice of making things more complicated, or making things more simple"
  • Dave Ungar, channeling Tony Hoare

• "Synchronization is the next goto"
  • Dave Ungar

• "When I was in the corporate world, my manager told me every presentation had to have a chart with two axes, and your system is here" (points to extreme top right of the graph)
  • William Cook

• Q: Why is there a notion of Primitive Type
• A: I just decided there would be
  • William "Enso" Cook

• Protobuffers are JSON for enterprise use
  • Jan-Willem Maessen

• "We get lots of c**p suggestions"
  • Program Manager for Major Programming Language, Redmond, WA

• "Types are anti-modular"
  • Gilad Bracha

• "You cannot read the code without looking at the class definition"
• "This file is just 44K"
  • Dan Ingalls on Smalltalk-72

• "There's something fundamental I don't understand
  • Andrew Black

• "You are a type guy or something, man!"
  • Robby Findler

• "What happens next is that nothing makes sense any more"
  • Alex Warth

• "'Underlying Abstract Problems' are for people whose concrete solutions are rubbish"
  • Some Guy from NZ

• "Semantics doesn't move fast enough for language evolution"
  • Dave Herman

-- JamesNoble - 22 Jun 2011

Sean McDirmid: Programming with Managed Time in Glitch

Most programming languages expose the hardware's ability to update global state at any time, leaving programmers to carefully coordinate state updates; an especially tricky task for reactive, concurrent, incremental, or iterative behaviors. As observed by Jonathan Edwards, just as languages runtimes now liberate us from meticulously allocating and freeing memory, they could also properly order state updates for us. In this spirit, we propose a new programming model, Glitch, where all updates between external events appear to execute simultaneously through a combination of incremental replay and update rollback. Programs in Glitch are then immediately responsive to event-induced changes, are iterative without extra logic, and are deterministic in their concurrency. By rationalizing state update, program executions in Glitch can also be replayed in an IDE, and can be revised incrementally under arbitrary code changes.

Mads Torgersen: Opening up C#

The C# team is changing its ways: the C# compiler is rewritten (in C#) with a public API that is immutable, efficient, detailed and full-fidelity. The whole compiler code base is open source. Language design notes are public – everyone gets to see how the sausage is made. In the talk I’ll give the lay of the land and see where the discussion goes. One interesting aspect is whether this codebase is interesting for teaching: the industry has come a long way since the dragon book.

Jonathan Edwards: Two-way Dataflow

Subtext is an experiment in radical simplification of application programming. The goal is to combine the power of frameworks like Rails and iOS with the simplicity of a spreadsheet. Mutable state is a notorious source of complexity in application programming and indeed has long been a central concern in programming language design. I propose a new approach called two-way dataflow which breaks the program into cyclic output and input phases. Output is handled with a form of pure lazy functional programming. Input is governed by a new semantics called one-way action which is a highly restricted form of event-driven imperative programming. Two-way dataflow has been designed not only to simplify the semantics of imperative programming but also to allow a representation in the IDE that, like a spreadsheet, provides a fully WYSIWYG programming experience.

Adam Chlipala: Separating Functionality and Optimizations: A New Programming Paradigm Enabled by Formal Methods?

Programming language design has progressed largely through the invention of new mechanisms for abstraction and modularity. We often expect our languages to enforce modularity, rejecting programs that would break abstraction boundaries. One important sort of modularity has largely eluded us: separating the functionality of a program from the optimizations that lead us to a performant enough implementation. To understand a program, a reader must wade through optimizations that obscure the underlying intent and structure. How might we get a programming language to enforce correct schemes of separating functionality and optimizations? Traditional modularity mechanisms don't seem up to the challenge, considering the breadth of optimization techniques that programmers feel compelled to apply in different contexts.

I suggest that we use one of the strongest known modularity mechanisms: formal (machine-checked) proof of adherence to specifications. A well-designed specification language lets us say exactly what we mean to say, in as few lines of code as possible. A well-designed proof system gives us plenty of flexibility in demonstrating why a program module meets its specification. These are the ingredients we need to support language-enforced modularity between features and optimizations.

In particular, we are working on a system codenamed Fiat, a library within the Coq proof assistant. The unifying metaphor is correct-by-construction program refinement, an idea with a venerable history in the world of program synthesis. The "functionality" part of a program can be a program with some nondeterministic operations. Our goal is to replace the nondeterminism with efficient code, in a logically sound way called refinement. Any notation for writing down refinement strategies constitutes the "optimizations" part of a program; mistakes in it cannot lead to "breaking the semantics" of a program, since Coq is checking each of our refinements, which must be proved correct. I will demo some of our experiments so far, refining SQL-style specifications into decently efficient functional programs.

Tom van Cutsem: The rise and fall (and rise?) of distributed programming languages

Context/abstract: the 1970's and '80s marked an era of innovation in the domain of distributed programming languages. Innovative languages such as Argus (Liskov et al), Emerald (Jul, Black et al), Occam (May, Hoare et al), Erlang (Armstrong et al), Modula-3 (Cardelli et al), etc. were all designed during those days. In the '90s, with the emergence of Java, we saw a shift toward so-called "middleware", such as Java RMI, CORBA, etc. where most distributed systems concerns were no longer dealt with in the programming language. Today, these object-oriented middleware systems are in turn largely superseded by "service-oriented architectures", web services or resource-oriented REST architectures. Whatever happened to good old distributed programming languages? Have they failed? If so, why? If not, why are they receiving so little attention? What can we learn from the past to improve the future of distributed programming abstractions?

James Noble: Capabilities, Trust, and Risk

The Escrow Exchange Contract has been used as a case study of building up complex and trustworthy systems from basic object capabilities, {in the context of concurrent and distributed programming. I'll present a Rational Reconstruction of the Escrow Exchange Contract case study, expressed in Grace, concentrating on the most essential issues of trustworthiness, and ignoring issues to do with distribution or more complex protocols.

Slides

Roberto Ierusalimschy: OO in Lua (or DIY OO Systems)

Lua presents a very basic and simple class-based object-oriented model. In this talk, I discuss how we can build rich prototype-based object-oriented models on top of the original simple model.

Slides

• -1: Reno 2010
• 0: Moutain View 2011 (Inaugural Meeting)
• 1: London 2012
• 2: Austin 2012
• 3: Aarhus 2013
• 4: Skamania 2014
• 5: Athens 2015
• 6: Los Angeles 2016
• 7: Lausanne 2016
• 8: Park City 2017
• 9: Antwerp 2018
• 10: Portland 2019
• 11: Nice 2019

The zeroth meeting of the group will be held 1st–3rd June 2011, probably at Google in Mountain View, California, USA. It may be relocated to downtown San Jose for logistical reasons.

Jan-Willem Maessen and Mark S. Miller are the hosts.

• Attendance List
• Local Arrangements — Hotel, restaurants, excursions, etc.
• Proposed Talks
• ScheduleAndLocation

• Dates: 2019 November 11–15
• Venue: Hôtel Nice Beau Rivage, Nice, FR
• Host: Manuel Serrano

The hotel booking form is attached at the bottom. In response to concerns about sending credit card details by email, there are two options:

1. The card number of the form is only used as a guarantee, so people that can generate a unique card number can use this method safely.
2. People can directly transfer the money (I have used transferwise recently and it is a very effective and cheap way to send money abroad) to the hotel bank account. The hotel bank account references are included at the end of this mail. They will STILL HAVE to fill and send the form, without their card number but with the reference of the transfer.

If you prefer option 2) the hotel recommends that they only transfer the money at the end of September or beginning of October.

Members attending

• Venue: Imperial College, London
• Time: Monday, February 27 to Friday, March 2 until lunch.
• Local organizer: Susan Eisenbach

Accommodation

We'll be meeting at Imperial College, London. Imperial maintains a web page for booking hotels with competitive rates:

http://www.imperial.ac.uk/conferences/hotel_dir.asp?campus_id=sk

The hotel we used last time (for the ECOOP PC meeting) was:

Grange Strathmore Hotel 41 Queen's Gate Gardens, London SW7 5NB

Another option - especially as funding seems ever tighter these days - is a hotel booking service - this one is apparently quite good:

http://www.booking.com/city/gb/london.html?aid=303948;label=london-HIOSi_4bM_KpzVbmtWDxsAS7897554141;ws=&gclid=COqVv-Cj86wCFUUPfAod9Dg3Bw

Workshop fee

The workshop fee covers food coffee, lunch, dinner, and an outing to the Design Museum. The cost is £285 + 1.345% credit card fee. Credit card payment can be made here:

http://www.imperial.ac.uk/click/1430

Getting there

The closest underground station to Imperial College is South Kensington. The workshop will be in 219A William Penny Lab. This is off the main walkway on the right as can be seen on the Campus Map:

http://www3.imperial.ac.uk/computing/about/gettinghere

Alternatively, you can take the underground to Gloucester Road station and then come into the main Computing Building at 180 Queen's Gate. Go up the main staircase and then exit onto the main walkway. The William Penny lab will be on your left (after passing a couple of other buildings).

Members

Visitors

Discussion Topics

• Evaluation of Language Design (Eelco Visser)
• Language design for cloud computing (Tom van Cutsem)

Tentative Schedule

• Dates: 2019 February 4–8
• Venue: Embassy Suites Hotel, Portland, Oregon, USA
• Host: AndrewBlack

The meeting will be in downtown Portland, at the former Multnomah Hotel, built in 1912. We have negotiated a room rate of $165 per night, which includes a full breakfast and a happy hour with drinks and snacks. Book here: https://embassysuites.hilton.com/en/es/groups/personalized/P/PDXPSES-IFI-20190203/index.jhtml

Originally, the hotel had 700 guest rooms, in the style of 1912, with bathrooms down the hall. The guest rooms have been completely remodelled, with two or three of the old rooms being converted into modern suites comprising a bedroom, bathroom, and living room. The reception and meeting rooms mostly retain their early 20th Century splendour.

The meeting schedule will follow our normal pattern, with members and visitors gathering on Sunday evening, and the meeting taking place Monday morning to Friday lunch-time. Wednesday afternoon will be reserved for an excursion, yet to be planned. We will eat one or two lunches and a dinner at the hotel; other meals will be arranged at nearby restaurants.

If you wish to arrive earlier or stay later, Mount Hood (skiing) and the Oregon Coast (storm-watching) are within easy reach for a day or overnight trip. If you are flying in to Portland International Airport (PDX), downtown is easily accessed form the airport using the MAX train (fare = $2.50).

-- AndrewBlack - 08 Oct 2018

Ivan Chermayeff wrote "Design is directed toward human beings. To design is to solve human problems by identifying them and executing the best solution." Steve Jobs wrote: "In most people's vocabularies, design means veneer. It's interior decorating. It's the fabric of the curtains or the sofa. But to me, nothing could be further from the meaning of design. Design is the fundamental soul of a human-made creation." We feel that this notion of design captures the essential difficulty of creating useful programming languages. Design issues are what programming language developers argue about amongst themselves. We have formed a working group of experts active in programming language research and development that is focused on discussion at the design level.

Our reason for forming a new group is that there is no existing venue that brings together experts to exchange and refine new ideas in programming language design. Computer science conferences no longer serve this role, because they are dedicated to the presentation of contributions that have been rigorously evaluated. While such conferences serve a crucial role in scientific progress, they tend to filter out discussion of early stage ideas as well as design issues that are qualitative in nature. Neither do they facilitate conversations on open problems and emerging issues. We note that some of the landmark papers on language design could not be published today: Liskov on data abstraction, Parnas on modules, or Landin on the next 700 languages. These papers consisted of informal but carefully reasoned arguments for the power of a new idea. These ideas were communicated promptly and triggered vibrant debates. We seek a venue that cultivates such ideas, arguments, and debates in a concentrated setting with a cohesive group of researchers and developers.

We have chosen to propose a new TC2 working group for two reasons. First, TC2 working groups are a proven model that has provided great benefit to our field, and indeed to some of us who are members of existing groups. Secondly, we feel that our charter complements the existing range of working groups. Groups such as WG 2.4 (Software Implementation Languages) and WG 2.8 (Functional Programming) specialize in specific kinds of programming languages. We believe it is vital to also have a forum that cross-fertilizes perspectives from the entire spectrum of programming language paradigms and communities, and that the lack of such communication has led in the past to wasteful intellectual duplication. Our initial membership already represents OO (static, dynamic, and Scandinavian), FP, distributed, parallel, LISP family, Java, C#, JavaScript^?. We intend to deepen and broaden this coverage as we fill out the initial membership.

WG 2.1 (Algorithmic Languages and Calculi) covers all programming languages, focusing on their formal aspects. In so doing they necessarily de-emphasize discussion of informal and qualitative design issues. We believe that sound theory is a necessary foundation for successful design work. Conversely, we would welcome the opportunity to bring emerging topics to the attention of WG 2.1 when there is a need for more formal investigation of a significant new idea. We might play an opposite role with WG 2.3 (Programming Methodology), designing language features in support of their methodological proposals. In this sense, we fill the gap between WG 2.1 and WG 2.3.

In sum, while our group overlaps to some extent with the subject areas of existing working groups, we differ more on an orthogonal axis, that of method. Our focus on design tempers the methods of mathematics and engineering with an appreciation of the pervasive influence of human factors throughout the act of programming. We feel the need to shift the discourse in this direction in order to progress as programming language researchers and developers. We further hope that this also is a step towards bridging the unfortunate chasm between industry and academic computer science. The charter of TC2 is “Software: Theory and Practice”. We respectfully submit that our group would help TC2 more completely fulfill that charter.

Our inaugural meeting was held June 1-3 2011 preceding PLDI, hosted by Google in Mountain View CA USA. A report on this meeting is attached. To summarize, we left the meeting with a consensus that it was a uniquely valuable experience and with the intention to proceed in formalizing the group, our first choice being an IFIP TC2 working group. The next meeting will be in the Summer of 2012, either at Imperial College in London or colocated with ECOOP in Beijing. Longer term, we are considering colocating on a regular basis with OOPSLA or ECOOP, and also sponsoring an associated workshop at those venues.

We thank the TC2 committee for entertaining this proposal and look forward to discussing its merits at the upcoming annual meeting.

-- AndrewBlack - 10 May 2011

Communicating event-loop concurrency and distribution

Mark S. Miller and TomVanCutsem

Communicating event loops is the concurrency and distribution model that underlies both the E and AmbientTalk programming languages. The model is founded on actors, but unifies the concepts of actors with objects in ways that set it apart from earlier "active object" or actor languages. The goal of this talk is to give a general introduction to the model. As we are promoting these ideas for inclusion in future versions of Javascript, we will explain a proposed embedding of the model in Javascript.

Presented slides

AmbientTalk: distributed object-oriented programming for mobile phones

TomVanCutsem (A short (30 min.) talk on AmbientTalk, the language I co-designed.)

AmbientTalk can best be summarized as "a scripting language for mobile phones". It's a dynamic, object-oriented, JVM-compatible, distributed programming language. AmbientTalk's focus is on applications to be deployed in so-called "mobile ad hoc networks" - networks of mobile devices that communicate peer-to-peer using wireless communication technology, such as WiFi or Bluetooth. We discuss how resilient mobile applications can be constructed with familiar building blocks like objects and messages, but also in what way these building blocks have to be adapted to fit the characteristics of mobile ad hoc networks.

Keywords: actors, event-driven programming, futures, remote objects, failure handling

Ensō

William Cook (note, I have another meeting I have to go to afternoon June 2)

I'm currently designing a new programming/modeling language/system, called Ensō. I would love to get feedback, as I have not spoken publicly about it before. Depending on the level of interest, this talk might go for 30 minutes or much longer. Ensō shifts the focus from individual records or objects, toward a holistic view of data as connected graphs. Graphs are natural representation for data, including object models, grammars, business models, databases, state machines, web sites, graphical user interfaces, and types. The structure of a graph can be described/constrained by other graphs, which are analogous to types. Types in Ensō, which are checked dynamically, go beyond structural properties to include invariants and other meta-data. Ensō allows graphs to be easily created, stored textually, and manipulated graphically or programmatically. Ensō programs are transformations or interpretations of graphs. Example transformations are merge, difference, rendering one graph into the space of another graph, and parsing. These operations are generic, because they are parameterized by the description of the kind of data that they are to operate upon. Types are also graphs, so in addition to being checked, they can also be combined, merged, and generated dynamically. At the core of Ensō are a family of self-describing graphs. Ensō is constructed in itself, and is being used to create a family of applications, including a web application language, a diagram editor (GUI) among others. This is joint work with Tijs van der Storm (CWI).

Batches: A unifying approach to remote execution, services, and database access

William Cook (note, I have another meeting I have to go to afternoon June 2)

This could be a very short talk, or a longer one. 15 to 45 minutes. I've given this talk a few times before, so I will not give it here unless people really want to hear it. It's about a finding a better way to do distributed objects. It also raises the question of how thousands of smart people could have persisted in making a huge mistake (CORBA/RMI/PRC/etc) in language design for over 30 years.

Combination of structure and behavior as an algebra

Erik Ernst^?

Very recently, a new advance was made towards the solution of an old problem in the language gbeta. The goal is to design classes/methods and combinations thereof in such a way that it always succeeds---even in cases where the classes/methods involved are not known statically---just like x+y always succeeds in the algebra of numbers with the operation '+'. One very persistent obstacle on this path is the fact that it breaks type safety to have a class that involves two different mixins with the same identity (same syntax) but different enclosing objects. This talk explains the overall problem of working towards this kind of safety, and in particular how one step in that direction has been invented and implemented recently.

Await! Taking the misery out of asynchronous programming

MadsTorgersen

In the .NET and Windows world - as in most places - threads are precious, and we cannot afford to waste them doing idle waiting. UI's are generally single threaded, and server scaling is often bottle-necked by thread count. So in the age of networks and the cloud, where latency is rampant, using threads to do the waiting just doesn't scale.

People therefore - wisely - take to callback-based models of asynchronous programming. Unfortunately, manual wiring of callbacks at any scale is agonizing, error prone an unmaintainable: one of the world's least appetizing uses of first-class functions!

In the next versions of C# and Visual Basic we use a future-based metaphor for outstanding work - we call them Tasks - and let you directly "await" them in the language. This lets developers keep the natural flow of their imperative code, without magically hiding too much of what's really going on: A compromise in the old debate around transparency of distribution.

As a meta-point (which we can go into or not) C# async is representative of the form of "in the trenches" language design that is necessary when evolving industrially-adopted far-from-perfect languages under highly specific technical and target audience constraints. The human factor of language design takes on a certain acuteness when your end goal is to sell copies of Windows!

Mutable state without imperative programming

Jonathan Edwards^?

Some day imperative programming will be seen as a barbaric practice from the stone age of software. Correctly sequencing myriads of memory accesses is a job for a compiler, not a human. Unfortunately imperative programming is still the only way we know for building programs with complex mutable state, a category that includes much application software. I am focusing on the problem of input processing in such applications. I propose to constrain the standard heap of objects and pointers into a special kind of tree structure. State mutation is constrained to an event driven pattern called hierarchical change-flow. These constraints enable the mutation of complex data structures to be programmed declaratively, that is, without sequential control flow.

Toward a declarative foundation for compositional distributed programming

John Field^?

The distributed systems community has made enormous progress over the past few decades building specialized systems that scale to handle millions of users and petabytes of data. However, combining individual systems into composite applications that are scalable---not to mention reliable, secure, and easy to maintain---remains a challenge. This is where programming models should be able to help: good programming models are designed to facilitate composing large applications from smaller components, and for reasoning about the behavior of applications modularly. However, there appears to be relatively little work on defining appropriate linguistic foundations for large-scale distributed systems.

In this talk, I will describe the Reactor programming model, which is designed to serve serve as a foundation for building distributed applications in a declarative manner. A reactor consists of two principal components: mutable state, in the form of a fixed collection of relations, and code, in the form of a fixed collection of rules in the style of Datalog. Multiple reactors, which model nodes in a concurrent or distributed system, communicate with one another using actor-style messages. Rules are used to specify both local computations and inter-reactor communication.

A notable characteristic of distributed systems design is that applications must make explicit design choices among consistency, availability, and partition tolerance (Eric Brewer's "CAP" theorem). I will show through an extended example that tradeoffs in the CAP design space can be viewed as simple code refactorings in the Reactor model.

This work is joint with Maria-Cristina Marinescu and Christian Stefansen.

Modularity & Visibility in Object-Oriented Languages

Kim Bruce

In the 1970’s and 80’s, there was incredible progress in the design of module systems for programming languages. Sadly, most of that work seems to have been forgotten in the last two decades. In particular, many users (and designers) of object-oriented languages have seemed to feel that classes could play the role of modules. We review some features of modules and propose a new module system for object-oriented languages that combines the information hiding and modularity of standard modules, with a notion of extension that fits the philosophy of object-oriented languages.

Exploring the Web Programming Design Space

Eelco Visser

The web is the domain of polyglot programming. A typical web program requires HTML, CSS, JavaScript^?, SQL, and your favourite GPL (Java, Scala, Ruby,...). All these languages are poorly integrated, giving rise to injection attacks and late detection of failures. With my students, I have been exploring the design space of linguistically integrated languages for web programming. WebDSL is a language for RESTful web applications and mobl is for stateful, client-side web applications, targeting mobile devices.

Instead of using a slide presentation, I would like to try talking about the language via code inspection. This would make it easier to have a conversation rather than a broadcast.

Dimensions of Domain-Specific Language Design

Eelco Visser

The goal of domain-specific language engineering is to systematically design a DSL for a domain. But what makes a good language? For a while I have been asking colleagues the question: "What is a good language design?" Markus Voelter and I recently wrote a paper in which we attempt to answer the question. That is, we present a framework for describing and characterizing external domain specific languages. We identify eight design dimensions that span the space within which DSLs are designed: expressivity, coverage, semantics, separation of concerns, completeness, large-scale model structure, language modularization and syntax.

Messages of Grace

James Noble

We are engaged in the design of a new object-oriented educational programming language called Grace. Our motivation is frustration with available languages, most of which are approaching 20 years old.

In this talk, I'll outline some principal features of Grace, discuss open issues, and listen to your reactions while all of the choices are still on the table. In particular, I'll give some examples from the design process so far, showing how conceptually orthogonal design decisions all too easily end up as tightly coupled gordian knots

Karl Lieberherr was half-right: a personal history of Object Ownership

James Noble

An interactive historical ramble through nearly twenty years of research in object orientation: from Software Visualisation in Self via incredibly complex Object-Calculus encodings to the latest results rejected from OOPSLA!

(With pictures.)

I have to give this talk later in the year so I could get started now, but will not give it here unless people really want to hear it. I think this may be relevant to a couple of other talks, but I always think it may be relevant.

We're all Postmodern Now.

James Noble

Another version of the postmodern talk that was quite fashionable about ten years ago. These days, Dick Gabriel and Guy Steele probably give better versions of this talk than I can manage.

This could be a very short talk, or a longer one. 15 to 150 minutes. At least half the talks above are explicitly postmodern in outlook, so people interested in the philosophical foundations might like this, but I've given versions of it a few times before, so I will not give it here unless people really want to hear it. Or we can discuss it in a bar after dinner.

Joint work with Robert Biddle, Carleton.

Languages for Distributed Algorithms

Annie Liu^?

This talk describes a language for programming distributed algorithms, compilation of the language to generate actual implementations, and powerful optimizations that incrementalize expensive queries and remove unnecessary messages. The language does not embody new concepts but is powerful and simple for expressing distributed algorithms cleanly, free of implementation details. For example, Lamport's distributed mutual exclusion algorithm can be written in 30 lines, almost exactly like the pseudo code description of the algorithm, but with a precise semantics for execution. A best effort for programming this algorithm led to about 200 lines or more in C and Java, about 100 lines or more in Erlang and Python, and 90 lines in PlusCal, a nonexecutable specification language for specifying distributed algorithms (all numbers exclude comments and empty lines). Our compilation method allows such programs to be generated automatically. Our optimizations allow more efficient implementations to be derived systematically. We have successfully experimented with specifying and implementing a variety of well-known distributed algorithms, including Paxos and Byzantine Paxos for distributed consensus.

Object Constructors in Grace

Andrew Black

I would like to talk about some of the challenges of designing Object Constructors in Grace. Why didn't we just copy Smalltalk or Java or Self? What are the desiderata for an object-oriented language that aims to be simple to explain and teach, to be as powerful as most existing languages, and to look forward to the world of manycore? Did we make the right compromises? And how does inheritance fit into the story?

Matching Contexts

Robby Findler

Redex is a domain-specific language for writing, testing, and typesetting operational semantics (and related tasks). Linguistically, however, the most interesting part of Redex is its pattern matcher. More interesting, in fact, that we realized when we started working on it. Specifically, Redex's pattern language has a notion of context-sensitive matching, inspired by Felleisen/Hieb-style semantics. As it turns out, the precise semantics of context decomposition has not been nailed down anywhere and is pretty subtle.

This talk explores the design space for the semantics of the pattern matching and tries to bring across how rich it is, how to best make sense of decomposition as it is currently bring practiced, and how to design a programming language around it.

Joint work with Casey Klein, Steven Jaconette, Jay McCarthy

Stop Fooling Around

David Ungar^?

It seems to me that most programming language 'research' is incremental. Is this a good thing? If not, what are the hard problems we want to be attacking? A language tends to optimize certain values at the expense of others, and thus the languages we design may be more context-dependent than we ever let on. Of course, I have a bit I can say from my perspective, but a discussion would be the main part. I would love to hear where each of us stand on these questions.

Harnessing Emergence for Manycore Programming: 
Early Experience Integrating Ensembles, Adverbs,
and Object-based Inheritance

David Ungar^?

This is a talk I gave at Onward 2010, about an attempt to get non-determinism and parallel ensembles into an object-oriented, Self-oidal language. The interesting part is that unintended consequences of the combination occurred for which I have no easy answers. If folks are interested, I would be happy to present the talk, and even happier to hear your thoughts.

• Date: Tuesday, 19 October, 2010 (?)

Attending

• Jonathan Edwards
• Andrew Black
• James Noble
• Dave Ungar
• Crista Lopes
• Eelco Visser
• ...

Manifesto

• From: Jonathan Edwards
• Date: Aug 15, 2010 7:32 AM
• Subject: Working Group on Programming Language Design

A few of us feel that there is currently no good forum for discussing programming language design issues; researchers interested in language design are isolated and lack a place to exchange ideas and criticism. Computer science conferences no longer serve this role, because they have become fixated on rigorous evaluation. There is nothing wrong with rigorous evaluation of things that can be so evaluated, but language design ideas, particularly in their formative stages where feedback is most crucial — and when there may be neither implementation nor experience with their use — cannot be so evaluated. Indeed, many landmark papers on language design could not be published today: Liskov on data abstraction, or Parnas on modules, or Dijkstra on goto. These papers consisted of reasoned arguments for the power of a new idea. We need a venue where such ideas and arguments are still welcome and where they can be refined by constructive criticism.

Ivan Chermayeff wrote "Design is directed toward human beings. To design is to solve human problems by identifying them and executing the best solution." Programming languages are not just for instructing computers — they are a medium for expressing software designs and communicating such designs to other programmers. Thus, an understanding of the human element is a vital part of good language design. As a result, programming language design is not just mathematics, science, or engineering — although it involves all of these. Other fields, like Architecture, recognize Design (with a capital D) as a distinct practice with its own methodologies. Steve Jobs wrote: "In most people's vocabularies, design means veneer. It's interior decorating. It's the fabric of the curtains or the sofa. But to me, nothing could be further from the meaning of design. Design is the fundamental soul of a human-made creation." Good design finds a balance between conflicting goals that are qualitative in nature. It requires insight, experience, and judgment; in sum: good taste. We need to affirm what really matters about programming languages, both to ourselves and the wider community.

For these reasons, the venue that we wish to develop must balance the benefits of openness and diversity against the need to maintain a high-quality membership and high-value conversations. A proven structure is that of an IFIP working group, with a slowly evolving permanent membership and a number of invited visitors, explicitly managed to maintain a high quality of discourse. Indeed, we have asked a number of WG members to suggest improvements to this formula, and they could not.

For these reasons we are considering proposing to IFIP Technical Committee 2 (Software: Theory and Practice) the creation of a new working group on Programming Language design. We would like to propose you as one of the initial members of this group.

Our first cut at the aims and scope of this incipient group are as follows.

AIMS

To explore and evaluate new ideas in the field of programming language design.

SCOPE

• the exploration of programming paradigms and major language features, both established and novel
• the design of notations for such paradigms and features;
• the design of programming environments that support the use of such notations;
• the investigation of software systems that implement such program notations;
• the evaluation of the above paradigms, designs and implementations, and
• the promulgation of "design thinking" among researchers, practitioners, students and teachers.

IFIP WGs typically meet for a week once every 11 to 13 months; there are no papers or proceedings, although papers often develop later from the discussions and presentations at the meeting. Please let us know whether or not you are interested in being part of such a group.

Andrew P. Black

Google
1600 Amphitheater Parkway
MountainView, CA

12:00-1:30 Lunch

12:00-1:30 Lunch

12-1:30 Lunch

An Essay on Language Design

Interests in programming language design:

• Concurrency abstractions (actors, channels, joins, STM, ...)
• Distributed computing abstractions (remote references, failure handling, ...)
• Parallel programming abstractions (data parallelism, fork/join, MapReduce, ...)
• Asynchronous and event-driven computations (futures, promises, reactive programming, ...)
• Object models (class-based, prototype-based, ...)
• Object composition (mixins, traits, ...)
• Language "symbiosis" (e.g. interoperation of dynamic languages and the JVM)
• Reflection (mirrors, intercession, meta-objects, ...)
• Meta-programming (macros, quasiquoting, ...)
• Psychology of programming (Green's cognitive dimensions of notations)

Talk to me about: AmbientTalk, Javascript, Erlang, Clojure, Scheme, Self, Ruby, Java, Occam, Fortress, X10, Chapel, ...

-- TomVanCutsem - 12 May 2011



Caesar Salad

Italian Chopped Salad (romaine, wild arugula, chicken, pancetta, roasted peppers, tomato, cucumber, fontina, red wine vinaigrette)

Tuttabella Pizza

Margherita Pizza

Penne with House Made Sausage Pasta

Mushroom and Artichoke Pasta

Gelato/Sorbetto

Aim

To explore and evaluate new ideas in programming language design. Our stance is that programming languages are foremost a medium for expressing the structure and intention of software, and communicating these to other programmers. As such human factors must weigh heavily in language design decisions, requiring a well-judged balance between conflicting goals that are qualitative in nature.

Scope

• exploring programming paradigms and major language features, both established and novel;
• co-designing programming environments with such language features;
• articulating more clearly the problems of programming that language features are designed to address;
• identifying key design decisions that balance conflicting goals such as usability, expressivity, and the ability to provide tool support
• combining experiences and perspectives from the full spectrum of language paradigms and communities;
• conversing at a conceptual level that practicing language designers find useful, not restricted to mathematical formalisms or empirical hypotheses;
• meta-discussion of techniques for evaluating language design decisions;
• promulgating the appreciation of design considerations among researchers, practitioners, students, and teachers.

Organization

• Group Members
• Meetings
• What we do at our meetings

Visitors

Our working group welcomes visitors. If you or someone you know is interested in language design and would like to share your ideas with us, please get in touch with one of our members, sharing a little bit about your interest.

Photos

Notes:

• Do not edit this topic, it is updated automatically. (You can also force an update)
• TWikiDocumentation tells you how to enable the automatic updates of the statistics.
• Suggestion: You could archive this topic once a year and delete the previous year's statistics from the table.

• RoadMap^?
• WebIndex: all topics in the WGLD web
• WebSearch: find topics

Tracking activity

• WebNews: selected changes
• WebChanges: recent changes
• WebNotify: email notification of changes
• WebStatistics: usage counts

Look and feel

• WebPreferences: values of variables
• WebContents^?: web specific entries in the side bar

• Aarhus2013
• AttendanceList
• Austin2012
• Boston2014
• GroupMembers
• GroupMission
• IFIPWorkingGroup
• LocalArrangements
• London2012
• MadsTorgersen
• Meeting2014
• Meeting2015
• Meeting2016
• Meeting2016Europe
• Meeting2017
• Meeting2018
• MeetingOneQuotations
• MeetingProceedings2014
• Meetings
• MountainView2011
• NiceMeeting2019
• PlanningLondon2012
• PortlandMeeting2019
• Proposal
• ProposedTalks
• Reno2010
• ScheduleAndLocation
• SiteMap
• TomVanCutsem
• UpdateWebPages
• VintoGroupMenuMeeting2017
• WebChanges
• WebChanges100
• WebChanges200
• WebChanges500
• WebCustomMenus
• WebHome
• WebIndex
• WebLeftBar
• WebNews
• WebNotify
• WebPreferences
• WebRss
• WebSearch
• WebSearchAdvanced
• WebStatistics
• WebTools
• WebTopicList
• WhatWeDoAtOurMeetings
• WilliamCook

See also the verbose WebIndex.

-- Eelco Visser

Talks are 50 minutes long, split equally between the presenter and the audience, metered by a chess clock. We encourage people to stray from a standard conference talk, as is can can be more interesting to discuss work in progress, open problems, and lessons learned. Monday is reserved for member talks, so that first-time visitors can get a feel for how the group works. The visitors give their talks Tuesday through Thursday.

We ask everyone to not use laptops or email during talks. We also have a rule against quoting anything said at the meeting.

-- Jonathan Edwards

Much of the content here has been borrowed from the web site of IFIP Working group 2.1, to which Andrew Black has been invited as an "Observer". He was impressed by the proceedings at WG 2.1, and believes that this procedure will make an excellent basis for the Working group on design. Of course, anything here can be changed if we find that it does not work for our group; conduct of our meetings is one of the things that we will discuss at the business meeting that will be held on the last day of each meeting.

Participants

Next to the members, participation is only open to invited visitors. Visitors are selected on the basis of the perceived potential relevance of their work to the concerns of the Design Group. Visitors are not supposed to sit in on the meetings and `observe'; they are expected to participate actively in discussions and presentations alike.

Presentations

Of course, a good talk on finished work that is central to the Design Group's concerns is also welcome. However, we also welcome work that is attempting to remake the paradigm, where it is to premature to ask for formal definitions and inappropriate to make detailed comparisons with prior work. Whatever the topic of a presentation, the assumptions must be out in the open, so that all participants can follow the reasoning. After all, we are a group of active language designers, and how a particular result was obtained, what reasoning led to a decision, or what motivated an approach, is often as interesting to us as the end result. In short: the speaker gets to choose what the talk should emphasize; the audience is entitled to expected that the story is coherent and intelligible. If it's not, we encourage both visitors and members to interrupt the speaker and ask for elucidation. However, the goal of the interruptions must remain the interrupter's ardent desire to understand and absorb the content of the talk; it must never devolve into a contest to show how much smarter one party is than the other.

From time to time a talk may prompt an impromptu discussion between the attendees, thus suspending the orderly progress of the presentation. Generally the chair will allow this as long as the discussion is germane to the higher purposes of the Working Group, but should cut it short when it threatens to become repetitive or pointless.

Scheduling

There is no fixed duration for presentations; talks run as long as they need and as long as there is sufficient interest, whichever of the two is shortest. The chair will cut off talks in which there is insufficient interest, which may take two hours or ten minutes. Clearly, under such a regime there can be no fixed schedule for presentations. At all times there is a tentative schedule, which is continually subject to change. To compound the complexity of the problem, the Design Group welcomes impromptu presentations, such as those that present a solution to an open problem of a previous speaker, or a substantive improvement on the prior speaker's approach.

The initial tentative schedule is drawn up using procedure that we will undoubtably evolve and refine. The meeting will commence with each attendee introducing themselves (name, affiliation, research interests), and, optionally, giving a sales pitch, of up to 5 minutes in length, of the presentation(s) that they would be willing to give, together with an estimate of how much time they require for the full-length presentation(s). The presentations can also be proposed ahead of time on this wiki. Once everyone has introduced themselves, and their potential presentations (if any), the participants rank the presentations they wish to hear. These rankings are collated, and are used to determine whether or not a presentation should be included in the initial schedule, and how much time is likely to be allowed for it. This initial schedule is subject to continuous revision as the meeting progresses.

-- AndrewBlack - 10 May 2011

-- WilliamCook - 15 Sep 2012